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