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
[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
