mo@messy.bellcore.com (Michael O'Dell) (03/13/91)
(The line-eater seems to be visiting Bellcore...) This is patent nonsense!!!! When was the last time you saw a new disk controller released with a new, dramatically faster processor????? For better or worse, the controller world is incredibly PRICE sensitive, NOT performance sensitive in general. In the time it has taken CPUs to increase a factor of, say 20 in speed with essentially constant or lower price, the bloody disk controllers are not much less narcoleptic than they ever were. Yes, the change from Multibus to VME did rev the controllers once, but boy, they are still rather sleepy. The notion that I'd be willing to bet my system performance even more than I am currently forced to do on what the controller companies do (or don't do) is simply insane. -Mike
jerry@TALOS.UUCP (Jerry Gitomer) (03/14/91)
mo@messy.bellcore.com (Michael O'Dell) writes: |This is patent nonsense!!!! When was the last time you saw a new |disk controller released with a new, dramatically faster processor????? |For better or worse, the controller world is incredibly PRICE |sensitive, NOT performance sensitive in general. Only if your view of the world is limited to micros, workstations, and minis. In the mainframe world disk controllers tend to be the keystone on which high-performance multi-user systems can be built. As a result performance has more value than price. (It is not unusual for a high end disk controller to be able to issue simultaneous commands to multiple disks and to be handle simultaneous I/O transfers while doing so.) |In the time it has taken CPUs to increase a factor of, say 20 in |speed with essentially constant or lower price, the bloody disk |controllers are not much less narcoleptic than they ever were. |Yes, the change from Multibus to VME did rev the controllers once, |but boy, they are still rather sleepy. The notion that |I'd be willing to bet my system performance even more than I am |currently forced to do on what the controller companies do |(or don't do) is simply insane. Perhaps this is why the mainframers all do their own disk controllers. Jerry -- Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA I am apolitical, have no resources, and speak only for myself. Ma Bell (703)683-9090 (UUCP: ...{uupsi,vrdxhq}!pbs!npri6!jerry
torek@elf.ee.lbl.gov (Chris Torek) (03/15/91)
In article <1504@TALOS.UUCP> jerry@TALOS.UUCP (Jerry Gitomer) writes: >Perhaps this is why the mainframers all do their own disk controllers. Probably true. I was quite shocked to hear that many SCSI controllers take several milliseconds, rather than a few tens of nanoseconds, to decode read adnd write commands. Reducing the latency on this *is* important. (I also found it surprising that SCSI controller people took so long to put 64 kbyte caches in. One obvious use is to do small reads by snarfing up the entire track, starting wherever the disk head is now, and sending the requested sectors back as they enter the cache RAM, i.e., with zero extra overhead but the next read for the same track can be answered without waiting for the disk to rotate. This requires either dual ported RAM or trickery: have the incoming bits written both to cache RAM and, if the sector is in range, to the SCSI-side FIFO pipe feeding back to the main CPU. The latter requires at least a sector sized pipe---which *is* available these days. The chip count does go up, but *read speed is important*.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
baum@apple.com (Allen Baum) (03/15/91)
In article <10951@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) writes: > > In article <1504@TALOS.UUCP> jerry@TALOS.UUCP (Jerry Gitomer) writes: > >Perhaps this is why the mainframers all do their own disk controllers. > Interestingly, the first use of the IBM-801 processor was as a channel processor for the IBM/370