[Simh] Limits on MSCP controllers

[Johnny Billquist]

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).

And yes, I know that HSC and other intelligent controllers using CI can 
have plenty of tapes and disks. CI is, admittedly, a little bit of a 
different beast, which is why I haven't brought it up.

I'm not sure it makes sense to compare MSCP with Massbus. MSCP is really 
transport agnostic and also rather device agnostic. All the disk 
geometry information is gone, and operations are much more abstract than 
in Massbus. And communication is more done in the form of datagrams. 
(You do touch upon some of it.)

You might mean SDI/STI (you do mention PHY)? But then again, SDI/STI is 
serial, while Massbus is parallel, and SDI/STI is point to point, while 
Massbus really is a bus going through multiple devices.

A bitmap for available disks would probably have been unrealistic. With 
unit numbers going to at least 12 bits, that would have required a 4096 
bit bitmap.

But anyway, the point was not to try and argue much around MSCP. I was 
merely questioning the 4 disk per controller limit that simh imposes, 
and noting that tmscp do not limit you to one tape per controller, which 
would have been logical if the aim was to correctly reflect what 
controllers and unit combinations were available on the systems back 
then from DEC.

   Johnny

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