bzs@world.std.com (Barry Shein) (11/24/89)
I've heard these I/O arguments for years. I think the first
centralized computing czar who ever saw a micro harumpphed "Oh yeah,
but how is it on I/O?"
It's true that mainframes, by definition, have awesome I/O relative to
anything else.
What I wonder is, how long before the micros just tear away this
barrier? I agree it'll be a long time before you have the I/O
*systems* that larger machines have, if ever (these days it's common
for mainframes to be ordered with 1TB disk farms, and backup
facilities, that would probably crowd your office.)
But pure I/O performance, measured blindly, on micros with a few
hundred to 1GB or so of disk?
I stress "measured blindly" because I'd consider all sorts of disk
buffering/caching to be fair play. Particularly if they're biased
towards the single-user system so the mainframe/mini couldn't just
implement the methods and jump back ahead. I'm sure such methods
exist, memory scheduling in large time sharers is much harder than in
single or very few user systems.
For example, we'll probably start to see 128MB main memory
workstations in the next couple of years as common. With effective
buffering and inevitably faster controllers and multi-ported memory
designs (?) how long do you think it will be before the difference
between micros/minis/mainframes starts to seem insignificant?
A better question: How fast is fast? How will we know? What's the
current situation? I don't think there are any widely accepted
benchmarks (Nelson? Aims?) I guess when it becomes the marketing rage
the benchmarks will show up.
I remember when they rolled in a 30MIPS 3090 and folks were sure the
mainframe crowd had gotten years ahead of the under-$100K bunch on
CPU. They were right, about two or three years ahead...and they're not
really keeping their heads above water on that front anymore (what's
single CPU performance on a 3090J?)
Or is I/O performance in micros like the weather, everyone talks about
it but no one does anything about it? NeXT made a lot of noise about
"mainframe I/O performance", but I had one of those systems for a
while and I didn't see anything impressive in their disk performance.
Just another windmill waiting to be toppled? Then what?
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzsseanf@sco.COM (Sean Fagan) (11/25/89)
In article <1989Nov24.033516.16214@world.std.com> bzs@world.std.com (Barry Shein) writes: >Or is I/O performance in micros like the weather, everyone talks about >it but no one does anything about it? NeXT made a lot of noise about >"mainframe I/O performance", but I had one of those systems for a >while and I didn't see anything impressive in their disk performance. Well, NeXT *does* have the right idea, almost. They have chips to offload some of the work from the CPU (the DSP and the I/O controllers). However, the bus doesn't seem to allow the DMA to happen at the same time the CPU wants memory. That is, somebody loses cycles. It might be possible to get around this, but I don't know enough about the machine to speculate too much (anybody from NeXT reading this?). -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
chasm@attctc.Dallas.TX.US (Charles Marslett) (11/25/89)
In article <3899@scolex.sco.COM>, seanf@sco.COM (Sean Fagan) writes: > Well, NeXT *does* have the right idea, almost. They have chips to offload > some of the work from the CPU (the DSP and the I/O controllers). However, > the bus doesn't seem to allow the DMA to happen at the same time the CPU > wants memory. That is, somebody loses cycles. It might be possible to get > around this, but I don't know enough about the machine to speculate too much > (anybody from NeXT reading this?). To get around the problem you really have to have more than one bus -- the old "can't have two things at the same place at the same time" problem. Some of the high end PCs have multiple busses along the lines of the DEC minis. That is, they have a CPU and local memory bus, and an external memory and I/O bus. They usually lock the high speed bus when the I/O bus is active, though, so it really just allows you to have memory faster than the I/O bus would allow (the whole point, originally). The point of this posting is that this is really what makes a mainframe: so if we put a micro togather with 4 486s (or 4 SPARCs) and 10 186s each controlling an AT bus running independently of each other, each processor having 13 high- speed channels to communicate with the other 13 processors, the box would REALLY have all the performance (if it were well designed) as a comparable mainframe. And it might be as big as one, and it might be as expensive as one. In fact, I get the feeling that something like this is what the next generation mainframe computers will be. > Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." > seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ > (408) 458-1422 | Any opinions expressed are my own, not my employers'. Charles Marslett chasm@attctc.dallas.tx.us
peter@ficc.uu.net (Peter da Silva) (11/27/89)
Two busses so DMA doesn't conflict with the CPU? The Amiga's had it since 1985. The major I/O processors (the Copper and Blitter) are limited to below the 512K line, and extra memory (FAST RAM) goes on a seperate bus. Other DMA devices may conflict with FAST RAM up to the 16 MB limit of the 68000, but the 68020 and 68030 can access memory beyond that (up to 64 MB of it on the current 68030 with an (as yet non-existant) daughterboard). Pretty good for a $1000 box. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
daveh@cbmvax.UUCP (Dave Haynie) (11/28/89)
in article <1989Nov24.033516.16214@world.std.com>, bzs@world.std.com (Barry Shein) says: > In-Reply-To: seanf@sco.COM's message of 23 Nov 89 21:25:24 GMT > A better question: How fast is fast? How will we know? It's fast enough when you don't mind waiting anymore. At least for an interactive computer like a PC or a Workstation. The reason personal computers have been gaining ground there past 5 years or so is that they're getting closer to what a larger number of people find acceptable for a larger number of tasks. Most folks don't mind a short wait for a spreadsheet recalculation, a DTP display, or a program load. After all, they just told the computer to do something, and expect it to take a certain amount of time to achieve that task. Of course, as computers get better, expectations change. You might be happy with 250kb/sec from your hard disk until you try a machine that gives you 1 mb/sec. Certainly the limit is the point where you don't notice any time between issuing the command and viewing the result. In fact, that's the problem I had with the NeXT machine -- I'm used to seeing a menu the instant I press the menu button. On a NeXT, it takes a little while. So I precieve the NeXT as being slow, even though it's at least 5% faster than my office machine in raw CPU power, and likely faster in I/O if it had a decent hard disk on it. Some jobs will practically always scream for more power, but I think in most cases the fact that you're interacting with humans is going to set the upper limit on the need for speed. > -Barry Shein > > Software Tool & Die, Purveyors to the Trade | bzs@world.std.com > 1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough