[net.unix-wizards] Advice on VAX peripherals wanted, note re HSC50

henry@utzoo.UUCP (Henry Spencer) (01/11/84)

Chuck Kennedy observes:

   Digital has announced the Digital Storage Architecture (DSA) which
   utilizes their nifty new HSC50.  The connection to the HSC50 is via the
   Computer Interconnect (CI) bus which has a 70Mbit/sec bandwidth.
   The HSC50 has some really neat features ...

One of the not-so-neat features is that the box on the other end which
actually runs the disks contains a cpu.  A small cpu.  I am told that for
some configurations it's a 730.  This may limit throughput.

   I only have two problems with the HSC50:
   	1)  If you don't run VMS (i.e. UNIX), you will have to write DSA
   	    code to run the HSC50.  This is probably more complicated
   	    than your average driver.  Besides, you have to yank teeth
   	    to find out all the information from DEC.

Bear in mind that the network architecture involved is approximately
that displayed by the UDA50 controller; I am told that Armando's driver
for that creature is about 30KB of code!  "More complicated than your
average driver" is probably the understatement of the century.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

geoff@utcsstat.UUCP (Geoffrey Collyer) (01/11/84)

A DEC salesperson told me that the HSC50 contains an 11/23 or an
11/24 (I can't remember which).

Geoff Collyer, U. of Toronto

shannon@sun.uucp (Bill Shannon) (01/11/84)

No, there is no 730 in the HSC50.  I believe there are several PDP-11's
and some special purpose processors just to move data.  One of the big
differences between the UDA and the HSC is that the UDA is attached
directly to a local bus (the Unibus), whereas the HSC is really
attached to a network (the CI).  Talking to the HSC is more like
writing a network protocol driver.  You'd like to use that nice, fast
CI bus to do other things besides just talk to your disk subsystem,
like use it as a very fast, very local network (which it is).

When I wrote the UDA driver I thought about trying to share some code
with a (future) HSC driver and decided that the two beasts were
different enough that it was not worth making the UDA suffer to fit
into the HSC scheme of things.  DEC actually has an "architecture" for
the interface between "class drivers" (e.g. a general DSA disk driver)
and "port drivers" (that actually handle getting the MSCP commands to
and from the device). At the time it seemed like a lot of excess
baggage (besides not fitting well into the UNIX kernel structure) but
as more MSCP devices come along it may be worthwhile.

Also, unlike something I read on the net, the shadowing feature of the
HSC is to allow you to maintain two disks with the same data invisibly
to the user, NOT write to tape.  I don't remember but there may be a
journally facility to log all transactions to tape.

All this is based on information I had 1.5 years ago.  Armando, correct
me if I remember wrong or things have changed.

steveg@hammer.UUCP (Steve Glaser) (01/11/84)

<non blank line>

I'd understood that the CI-780 and CI-750 interfaces to the VAXcluster
assumed that system software uses the page tables like VMS does (the
HSC50 is just part of the system, it hangs on the CI bus and talks to
disks and tapes).  The VAX architecture manual used to describe a
number of "reserved for software" bits in the page table entries and
Unix uses these bits differently than VMS does.  Apparently, the CI
series interfaces "know" about page tables, but assume those bits are
used the VMS way.  This would require changes to the 4.1 (or 4.2)
paging system to be usable.  I also think the DR-780 has the same
problem.

The new VM architecture of 4.3BSD may fix this (if it ever makes it).
DEC's product version of Vax/Unix may also fix this.  My understanding
is based on a conversation with Bill Shannon at the Boston USENIX - DEC
may have changed the hardware since then (It wasn't announced then
anyway) [Armando, are you listening?].

In any case, it's going to take more work than just writing another
driver, if only because it's another SBI (CMI) device so it doesn't fit
into the model of an ordinary Unibus or Massbus device.


	Steve Glaser
	tektronix!steveg		UUCP
	steveg.tektronix@rand-relay	ARPANET/CSNET

leichter@yale-com.UUCP (01/16/84)

A HSC50 contains multiple F-11's; these are the chips in both the 11/23
and 11/24, which differ in the backplane:  11/23 is Q-bus, 11/24 is Unibus.
(Actually, to be complete:  11/23 is 18-bit Q-bus, 11/23+ is 22-bit Q-bus.)
It isn't particularly meaningful to ask whether the F-11's inside an HSC-50
are "11/23's" or "11/24's".

While the DSA protocol may be complex, it has two advantages over usual
disk-driver interfaces:  It looks like a fairly high-level network protocol,
not a series of random read-only, write-only, and read-write bits plus
interrupts and timing constraints; and it is done, once and for all:  New
disks can connect to the HSC-50 without the host talking to it knowing that
they are new...the HSC-50 protocol stays unchanged.
							-- Jerry