Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!swrinde!mips!spool.mu.edu!uunet!olivea!mintaka!spdcc!iecc!Postmaster
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Can old architectures run fast?
Message-ID: <9105091145.AA04421@iecc.cambridge.ma.us>
Date: 9 May 91 15:45:19 GMT
Sender: Postmaster@iecc.cambridge.ma.us
Organization: I.E.C.C.
Lines: 45
In-Reply-To: <c506634.3284@umcvmb.missouri.edu>

In article <c506634.3284@umcvmb.missouri.edu> you write:
>Can *all* the price performance difference be attributed
>to the presence or absence of a high speed IO system?  

No, a lot of it is due to high-performance shared memory and a lot of
reliability and servicability hardware and microcode.  The 370/ESA I/O
system does some impressive stuff in the interest of performance.  For
example, each disk drive is typically attached to several controllers, each
of which is attached to several channels.  This means that there are
typically four or more different physical device addresses for each disk.
One of the improvements in the new I/O system is that the CPU just issues an
operation for the logical disk, and the channels find a path that isn't
already in use.  There is also a lot of buffering in disk controllers, as
much as 128MB (that's MB, not KB.)

In fairness, there is also a lot of glop, particularly in the disks, to
support designs that made a lot more sense in 1964 than they do now.
Traditional IBM disks allow variable length hardware disk blocks, and each
block can have a key of up to 256 bytes.  You can have the disk controller
search down a track or cylinder looking for a particular key.  This made
perfect sense for ISAM on a 360/30, when the CPU stopped during disk I/O
anyway, but it's pretty awful now.  IBM has for 20 years had more reasonable
index schemes based on B-trees, and disks with fixed size blocks addressed
by block number rather than cylinder, track, and record, but there is still
support for the old stuff.  One might reasonably expect a new design not to
have hardware keys on the disk.

>Also, is there anything to prohibit a RISC based machine from having a high
>speed IO subsystem?

In most cases, no.  In some cases there might be problems with bus
contention, cache collisions, etc.  Almost all 3090 systems have more than
one CPU, and they all have many channels, which affects the design quite a
lot.  By the way, the 3090 channels each contain an 801 RISC micro to
control the I/O, so in that sense there is already a RISC with a fast I/O
system.

>  Would adding this make the machine cost as much as a 3090?

I expect it'd be close enough that the price difference wouldn't be
compelling.

-- 
Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl