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 <[email protected]> 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
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
