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 [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
