🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.super
Article #171

I/O subsystems are hard

#171
From: Martin Fouts
Date: Thu, 07 Jun 1990 18:24
50 lines
2993 bytes
In article <6392@amelia.nas.nasa.gov> yamo@wk46..nas.nasa.gov (Michael Yamasaki) writes:

   In article <56754@bbn.BBN.COM> lkaplan@BBN.COM (Larry Kaplan) writes:
   >
   >There are some true "killer micros" that address I/O issues on the market
   >right now.  BBN's newer "Butterfly" machine (TC2000) can be configured with
   >one I/O bus (read VME) for about every TWO processors.
   > [...]
   >These busses communicate with memory at a peak of 8 Mbytes/sec.  
   > [...]
   >One existing customer has 9 disks on five I/O busses.
   >

   Combined peaks of these five I/O busses is somewhat less than a single
   HPPI interface, less than half of an HSX (at 100 MBytes/sec.). Again,
   the numbers I used for the Cray 2 were for a typical single processor job
   with 50 or so other users on the system.

   >This amount of I/O is starting to look reasonable for a killer micro.
   >Some work remains to be done, however, in getting the software to effectively
   >use all of the bandwidth.
   >

   (an exersize for the reader? ;-)  Really, this doesn't seem like a trivial
   problem to me.

Let me agree completely.  I/O subsystem hardware is hard to do.  I've
just helped design an I/O subsystem with a peak 400mb/s aggragate rate
across 4 100 mb/s channels.  It required 10ns clocks and ECL logic and
a lot of wires.  It isn't going to be available on a killer micro (;-)
Once the hardware tradeoffs were made to get a working design, the
software was also hard.  This system required multiple cpus and
several memory to memory transfers (mostly between fifo's at interface
translators.  To avoid latency transfers had to be minimized,
requiring a lot of short circuting and duplicate state machine
management on both sides of the interface.  Latency requirements also
demanded that as much overlap as possible be provided in I/O
operations.  Doable, but not an exercise for the reader.


--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts  ARPA:  apd!fouts@ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

If you can find an opinion in my posting, please let me know.
I don't have opinions, only misconceptions.
Technical Details
Message-ID: <430@garth.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!Teknowledge.COM!unix!garth!fouts@bozeman.ingr.com (Martin Fouts)
References: <201@csinc.UUCP> <253@garth.UUCP> <202@csinc.UUCP> <292@garth.UUCP> <10280@batcomputer.tn.cornell.edu> <359@garth.UUCP> <6374@amelia.nas.nasa.gov> <56754@bbn.BBN.COM> <6392@amelia.nas.nasa.gov>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!Teknowledge.COM!unix!garth!fouts@bozeman.ingr.com (Martin Fouts)
From: fouts@bozeman.ingr.com (Martin Fouts)
Newsgroups: comp.sys.super
Subject: I/O subsystems are hard
Message-ID: <430@garth.UUCP>
Date: 7 Jun 90 18:24:49 GMT
References: <201@csinc.UUCP> <253@garth.UUCP> <202@csinc.UUCP> <292@garth.UUCP> <10280@batcomputer.tn.cornell.edu> <359@garth.UUCP> <6374@amelia.nas.nasa.gov> <56754@bbn.BBN.COM> <6392@amelia.nas.nasa.gov>
Sender: fouts@garth.UUCP
Distribution: na
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 50
In-reply-to: yamo@wk46..nas.nasa.gov's message of 30 May 90 16:40:21 GMT