[Simh] Limits on MSCP controllers

[Mark Pizzolato]

On Monday, June 24, 2019 at 12:32 AM, Johnny Billquist wrote:
> My point was simply that getting the response back that simh only allows
> 4 disks per controller because that was what the real hardware allowed is a
> rather bad answer (in my opinion), especially since simh don't even follow
> what the real hardware did when looking at tmscp. There, the equivalent
> hardware was the low end controllers that only allowed one tape drive per
> controller, but simh allowed more than one tape drive per tmscp controller,
> while simulating those controllers. So there is no real consistency in what simh
> does and allows. So the 4 disk per controller limit is rather arbitrary (again, in
> my opinion).

Without talking to Bob about exactly how he got to the TMSCP (pdp11_tq)
implementation, I would guess that the TMSCP support actually started from 
the working MSCP (pdp11_rq) implementation and tape activities/operations 
were added.  That would be why it started out having 4 units.

After that happened, he went back and added the extra controllers to 
pdp11_rq.

Meanwhile, after all of this discussion, I've added SET RQ DRIVES=val where 
val can be anything from 4 thru 254.  The RQ devices (RQ, RQB, RQC and RQD)
start out as 4 drive controllers like they've always been, but each can now be 
expanded in arbitrarily unreasonable ways.  :-)

- Mark

> On 2019-06-24 04:13, Timothe Litt wrote:
> >
> > On 23-Jun-19 20:01, Johnny Billquist wrote:
> >>
> >> Timothe Litt clearly knows this better than I do. His mention of the
> >> attention message jogged my memory a bit. There are just
> >> notifications going the other way about available disks. And ports
> >> are not really relevant. In RSX, they are then obviously matched
> >> against what you configured in your SYSGEN. Disks which do not match
> >> any configured device are just going to be ignored. No dynamic adding
> >> of disks possible. And unit numbers can be totally unrelated between
> >> one controller and the next, and have nothing to do with the device
> >> numbering inside RSX. So DU5: can map to unit #42 on the third
> >> controller. RSX will happily do that mapping.
> >>
> > MSCP is basically an evolution of the Massbus protocol, on a different
> > PHY, and informed by the TOPS-10/20 experiences with high-end  (large,
> > redundant, on-line serviceable) configurations.  The attention
> > messages are analogous to the attention summary register bits on a
> Massbus.
> > Although intended to be scalable, the design was driven by the initial
> > implementations, which were the HSC50 (with the SDI/STI PHY). Later,
> > we benchmarked configurations with 100s of disks - which required many
> > racks and long SDI cables.
> >
> > TMSCP design lagged MSCP - with the required allowances for tapes -
> > again using the Massbus model at the PHY (one port connecting to a
> > formatter that could have multiple drives.  But a lot of the Massbus
> > ugliness is abstracted away from the OS.
> >
> > In VMS (and the TOPS-10/20 CI implementations), attention messages can
> > materialize units on the fly.  The IO working group that defined
> > (T)MSCP expected all configuration to work this way. In retrospect, it
> > would have been better for the OS if the controller could provide a
> > bitmap of what units are present on a controller.  But SDI/STI
> > (they're the same
> > phy) were designed for hotplug and for sequenced power-on.  There is
> > no "drive present" wire - you have to ask a drive to do something in
> > order to determine if something is plugged in.  So the controller
> > can't know - unless it were to poll its ports.
> >
> > As Mark pointed out, VMS stand-alone backup does try to enumerate all
> > the devices - which takes forever and a day.  Besides the time it
> > takes to spin up a disk to determine its geometry (or time out if a
> > port is empty), there are a limited number of credits (outstanding
> > command
> > buffers) available in the controllers.  So sending ~64K "get unit
> > status" commands to each controller is a painfully slow process - and
> > frustrating where there are often only 1-4 units on each controller.
> > For scale, consider that a 4-XMI system using just KDM70s could have
> > 23 KDMs to poll; a CI system could have 31 HSCs, and an LAVC - well, lots.
> >
> > RSX (and IIRC RT) statically configure configure MSCP disks as Johnny
> > describes.  This is only practical for the relatively small
> > configurations that they support.  I doubt that the unit attention
> > messages are completely ignored; though not used for configuration,
> > they also tell the OS when a disk has spun up (or down) based on an
> > operator pushing the 'online' button.  This is especially true for
> > removable media (e.g. RA60), but also applies to RA8x/9x.  And the
> > case of an operator switching unit plugs on a drive.  (Humans do the
> > strangest
> > things...)
> >
> > After the UDA/KDB50s,  U/Q (T)MSCP devices moved away from the SDI/STI
> > interface - but that's transparent to the OS.  For the low end, there
> > was no need for the hotplug or distances supported by the SDI/STI
> > interfaces.
> >
> > And of course, much later the HSCs supported SCSI disk and tape. And
> > the HSD/HSZ controllers.  I wasn't involved in those, so I don't
> > remember their configuration limits.
> >
> >> And by the way, if the goal of simh was to try and act just like
> >> existing hardware, then you should not be allowed to have more than
> >> one tape drive per tmscp controller, since that was the way of all
> >> DEC tmscp controllers.
> >
> > Be careful about saying "all".   The UQ TMSCP-only controllers bundled
> > with the TxK[5,7] are one drive/controller.  But that is not the
> > universe of TMSCP controllers.
> >
> > The HSC50/60/70 support multiple drives per controller (and per K.STI)
> > e.g. the TA78/79).  The HSC50 predates the T[UQ]K50.
> >
> > The KDM70 on the XMI backplane, previously mentioned, supports up to 2
> > active STI ports, each of which can have a formatter (subcontroller)
> > with multiple drives.
> >
> >> But tmscp itself also certainly do not have such a limitation, and in
> >> this case simh do deviate from what the real hardware did. One TQK50
> >> (or TUK50) per TK50, and so on...
> >>
> > SimH has always started with what real hardware does as its design
> > principle.  However, it doesn't implement all of the real hardware.
> > People have software that ran on systems that had more hardware than
> > the implemented devices support.  So it does bend configuration rules
> > from time to time.  This is important in cases where SimH implements
> > low-end models, but people have disk images from large configurations
> > of high-end models.  The RAUSER (arbitrary size disk) is one such.
> > Being able to configure more controllers in SimH than there are
> > physical slots for in hardware is another. These deviations work
> > because the OSs tend to use scalable abstractions, and can configure
> > devices that could not be placed in real machines.
> >
> > SimH is really about preserving the ability to run legacy software,
> > not slavishly implementing hardware.  As Bob has documented, there are
> > certainly cases where an OS depends on low-level hardware design.  In
> > those cases, strict fidelity matters.  But there are also many cases
> > where the OS is tolerant of of "extensions" - like infinite bus
> > lengths/slot counts.  The goal has been for SimH to run as much
> > software from physical systems as possible, modulo the ability to
> > emulate the hardware. It has not been a goal to, nor is it the case
> > that, every SimH configuration can be implemented on real hardware.
> >
> > Note also that as a rule, SimH does not implement hardware features
> > unless some OS requires them - this is especially true of
> > maintenance/diagnostic features.  There are also subtle differences -
> > e.g. an OS under SimH may carefully order & fence disk writes to
> > ensure file system consistency in failure cases.  But while SimH will
> > present them in order to the host OS, the host OS and/or hardware may
> > not have the desired semantics. (E.g. due to caching, position
> > optimization.) Bob & I had many discussions (and differing opinions)
> > about how important these effects are in the very early days of SimH.
> > (While we were still at DEC...)  The decision was to ignore these
> > issues - even with host OS support, there's no good way to divine the legacy
> OSs'
> > intent and pass it on to the host.  Here SimH performance trumps fidelity.
> >
> > With respect to configure being in HIB - I'd expect this, since most
> > of the time it's waiting for IO - probably AST-driven, though I don't
> > remember having to debug that code.
> >
> >> Johnny
> >>
> >
> > _______________________________________________
> > 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
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh