On 24-Jun-19 15:18, Clem Cole wrote: > > > On Mon, Jun 24, 2019 at 2:13 AM Timothe Litt <l...@ieee.org > <mailto:l...@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...
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
