[Simh] LAVC

[Johnny Billquist]

On 2017-03-11 23:55, Timothe Litt wrote:
> Not just named buffers.  *Virtual* named buffers; the interface takes
> pointers to page tables (or, things that look like page tables in a
> couple of cases).  Process, system and global entries.  The only
> restriction is that all PTEs must be valid (e.g. buffers are virtually
> addressed, but must be resident) And interlocked queues shared with the
> host for commands and responses.  That's the full 2-stage interlock of
> the VAX queue instructions.
>
> And yes, there are virtual circuits established between hosts and
> storage controllers. credit-based flow control.
>
> CIport (host-CI) interfaces are among the most complex; they provide a
> mostly hardware-managed network stack.  The HSC does disk level
> optimization; responses (and partial buffer transfers) happen in any
> order, can be interleaved across the named buffers.  The HSC also has a
> command processor, and it's possible to do 3rd party IO, as well as
> physical backups.

Right. The controller is complex. That is where a lot of work is if 
anyone every wants to emulate this. The transport of the bits is the 
easy part.

By the way, all MSCP controllers can do optimizations such as reorder 
operations, and possibly run them in parallel as well.

> LAVC replaces the PHY, more or less.  Don't forget TMSCP & DUP.

Right. Especially TMSCP. I doubt DUP makes much sense, except for just 
the principle of emulating it all. DUP don't otherwise make much sense 
in an emulated environment, as it dealt with error recovery and low 
level formatting and diagnostic, and what not.

But none of that is HSC specific anyway.

> There *is* microcode in the HSC - the K.xxx cards are 290x based (did
> the data moving) & had loadable microcodes.  The J11 firmware (pdp-11
> code) handles command decoding, scheduling, error reporting & the CLI.
> But the data transfers are off-loaded to microded engines.   If you want
> to run the pdp-11 code, you need to emulate those devices too.

Oh, I didn't mean to imply that there wasn't microcode anywhere. But the 
HSC as such is a PDP-11. The software that it runs could be called 
firmware or software. People tend to confuse these things and think they 
are separate things, and both have to exist.
If you are going to emulate a HSC, you can either do it as a box, in 
which case you'd implement the protocol it does, and write your own full 
implementation. Or you could emulate the hardware, in which case you'd 
run the same software as a real HSC. And in that case you'd then have to 
decide if you wanted to emulate each card as a box, or if you'd want to 
emulate the hardware on that card, in which case you'd want to run the 
firmware of that card.

Heck, the J11 also have firmware. I haven't seen anyone ask for that 
yet. Instead people implement a PDP-11, and try to make it behave like 
the J11.

> There is exception handling when one cable set breaks (don't remember
> exactly the division of responsibility); there are also dual port disks
> (across HSCs) for redundancy.

Yes. Normally traffic is shared on the two paths, but it works if only 
one path exists as well. Exactly which parts are done in hardware, and 
which parts are done in software I don't know either.

And yes, for high availability, you are supposed to have two HSCs, and 
use both ports on disks, connected to the two HSCs, and the disks should 
also be shadowed, so that all data exists on two disks, so there is 
redundancy all the way.

> That's just off the top of my head.  It's a non-trivial project.  Er,
> P.roject.  That's a very large 'P'.
>
> Could be fun.  But non-trivial.  And there are many layers of research
> required to get it right.

Agreed. This would be a huge project. Interesting in some ways, definitely.
But to be honest, I fail to see the benefit.
For clustering, you can already do this with LAVC.
For disks, you already emulate MSCP and TMSCP, through other controllers.
For high availability and redundancy, you do that on the host system, 
not the emulated one.

So, why would people do this?

	Johnny

>
> On 11-Mar-17 16:53, Paul Koning wrote:
>>> On Mar 11, 2017, at 4:42 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>>
>>> On 2017-03-11 22:33, Tim Stark wrote:
>>>> Yeah.
>>>>
>>>> I believe so.  That is possible to replace CI/DSSI physical layer with UDP over IP multicast to embed SCS/MSCP packets to other hosts and HSCs at once.
>>> Of course this is doable. The network part itself is not even hard. The big work is actually implementing the CI controller emulation. Once you have the packet to send out, you just send it.
>> It's probably not as easy as you might think.  As I mentioned, the CI protocol (SCA) is an RDMA protocol ("named buffers").  If you want to emulate CI, you'd have to emulate that, because the host code that talks to the CI expects that service, and the real CI interfaces provide it on the I/O card.  You could use the LAVC protocol spec (if there is one available) as inspiration, but it may be that LAVC doesn't provide the same application services as SCA does.
>>
>> 	paul
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol