[Simh] Limits on MSCP controllers

[Timothe Litt]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20190623/8b342a7c/attachment.html>