[Simh] Limits on MSCP controllers

[Timothe Litt]

On 24-Jun-19 15:18, Clem Cole wrote:
>
>
> On Mon, Jun 24, 2019 at 2:13 AM Timothe Litt <litt at ieee.org
> <mailto:litt at ieee.org>> wrote:
>
>
>>
>     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. 
>
> That was certainly my impression/memory.
>
As is often the case, things turn out to be complicated.  Here's a more
detailed version.  In an off-list note, Bob pointed out that MSCP
originated in a project he managed that was to develop the "next
generation" disk controller - a forerunner of the UDA.  That project
didn't start with "let's replace Massbus"; its premise was "it's
necessary to move host functions to the controller to support high(er)
density disks.  Especially ECC and error recovery".  It's original PHY
was the memory interface model of the PDP-15/PDP-11 coprocessing pair
(UC15), which became the UQSSP.  Bob reported that he took this project
from concept through the UDA50 prototype - at which point the group
moved to Colorado (and he didn't).

I didn't mean to suggest that MSCP started as an explicit effort to
model/replace/extend Massbus.  However, if you extract the Massbus
protocol from the PHY (OSI L1) and registers, and consider the entire
DSA the similarities are striking.  I wasn't there at the beginning, so
I can't say when/how that came to pass.  But I can say that the earliest
public descriptions of DSA that I attended (mid-70s) described DSA (the
architecture initially encompassing CI, (T)MSCP, and SI (SDI/STI)  in
those terms.  And when I was involved with DSA architecture some years
later, Massbus was used as a reference for many conversations.  By then,
we were talking about 3rd party IO commands and other support for
host-based and cross-HSC shadowing.  But attention, on-line, dual port
issues and many others were mapped between the the two for discussion
purposes, and ensuring that MSCP had at least equivalent capabilities to
Massbus was a litmus test.

The primary TOPS-10 architects (who were present through the early
evolution - after Bob's project & through the HSC) directly told me that
that Massbus was their reference model for DSA.  Not surprising, since
Massbus, with all its warts, was the closest thing to a high
availability, high performance bus that was available to them. 

And since TOPS-10 SMP was the company's first serious/successful effort
at a large scale, highly available, high performance, serviceable
system, it certainly made sense for DSA architects to refer to it for
requirements, successes, and pitfalls.  Of course I did when I made my
(small) contributions to the (T)MSCP architecture process.

However the similarities came to pass, I found viewing DSA as an evolved
Massbus to be a useful model, with a lot of support for that perspective
in the specifications.  MSCP contains the high-level protocol of Massbus
drivers (and much more) through the drive control logic/formatter.  SI
replaces the DCL/formatter to drive "bus" of Massbus -- SI is serial,
ruggedized and capable of quite long runs.  But it carries much the same
low level drive commands.  (Note that there's a long history of
serializing parallel buses as technology evolves, e.g. PCI -> PCIe ->
CSI, a.k.a. quickPath). The host ports (UQSSP,KLIPA,etc) replace the
registers and DMA channels.  Command and function names from Massbus
spec & drivers often appear in the MSCP spec versions that I used...

DSA was ahead of its time in considering storage as a network
architecture - preceding today's NAS, storage appliances, RDMA & iSCSI. 
It was successful in maintaining host compatibility as technologies were
replaced/elided.  E.g. the devolution from SI to parallel drive
interconnect in integrated controllers; then DSSI and SCSI; transports
from CI to NI, disaster-tolerant clusters over fiber; controller-based
shadowing & RAID, variable density (banded) geometries, and ...  About
the only things that changed in the class drivers were device names. 
And even the port interfaces were remarkable stable.  Of course the
error log interpreters had more significant updates...

Also, dusting off memories, enumeration does have a little more support
in MSCP than I previously indicated; there's a "get next unit" modifier
bit for the "get unit status" command that helps.  But it's still
painfully inefficient for the reasons given.

Some form of block transfer (e.g. give me all known units), such as a
bitmap would have been much better.  64K units as a bitmap would fit in
a 16-block (512 byte block) transfer, which is hardly unreasonable. 
Being sparse, it would not have required much controller memory.  But as
this was settled before I arrived on-scene, it's academic.

Johnny's sub-unit confusion probably derives from SCSI LUNs; e.g. the
disks off a RAID controller that takes a single SCSI bus ID.   I think 4
bits for LUN addressing was common there.  Similar schemes exist in
PCMCIA and PCI, where a single bus address may have multiple functions
(independent "devices") "behind" it.

I don't recall a "unit offset" in the HSCs - but that could easily have
escaped me.  I was very happy to let others do the setup of the very
large configurations used for benchmarking...I had many other reasons
for crawling under raised floors...

Enough history - back to my regularly scheduled programming...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20190624/23e7b7fa/attachment-0001.html>