Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!portal!cup.portal.com!cliffhanger
From: cliffhanger@cup.portal.com (Cliff C Heyer)
Newsgroups: comp.arch
Subject: *big iron*
Message-ID: <22488@cup.portal.com>
Date: 24 Sep 89 18:39:41 GMT
References: <21962@cup.portal.com> <1989Sep12.031453.22947@wolves.uucp>
  <22130@cup.portal.com> <1989Sep16.044013.429@wolves.uucp>
  <259@ssp1.idca.tds.philips.nl> <22308@cup.portal.com> <7981@cbmvax.UUCP>
  <11538@burdvax.PRC.Unisys.COM>
Organization: The Portal System (TM)
Lines: 134

>In <22308@cup.portal.com> Cliff C Heyer wrote:
>> the *big iron* guys use MIPS as a trojan horse to hide the *real*
>> performance issue - "real world" I/O bandwidth. Lets blow their
>> cover!)
Eric S. Raymond responded...
>Huh? The `big iron' crowd is happy to talk I/O bandwidth, it's about the
>only place general-purpose mainframes got room to shine any more. It's
>the *PC/workstation* crowd that's prone to yell about MIPS and whisper
>about I/O performance.

Guess you got my point...but still I can express it better:
To clarify, *big iron* guys emphasize I/O on
their *mainframes*, but not on their *PCs*. Instead, they emphasize
MIPS on their PCs. Of course many would say that PC users are not
"interested" in I/O BW, and I agree with this. BUT there is a convenient
dual purpose here for the *big Iron* guys.  The following is my
theory:

Let me play *joe Mr. Marketing VP* who will get a BIG promotion if
profits are maximized. Joe wants two things: (1) saturate the market
with *slow* hardware so users will have to *buy more* in the future,
and (2) don't tell people how slow their PC hardware is compared to
*big iron* so as not to call attention to the relatively slow speed. 
Why have people complaining and demanding better performance if
you can avoid it? 

This is the only answer I can come up with to explain why IBM 
consistently puts out PCs that are substantially below average in "real"
disk I/O speed: 200KB/sec. Just look at Byte benchmarks. Plus I'm
getting LOTS of mail now further confirming this. Now I'm talking
about hardware bought & configured by IBM. I know you can
plug in aftermarket disks w/custom drivers that may blow away
the original equipment.

Companies are trying to promote the image that they are selling "state
if the art" hardware, but if you look at "mainframe" specs you see
how far from "state of the art" you really are. Lets just be honest here,
I say why let a company tell you that your buying the "best" when the
truth is you are buying mid 70's level performance. I know I know,
it doesn't cost $5,000,000. That is an accomplishment! My beef is how 
we are told all the time that we are buying the "best" when in fact,
we are often buying below the current average - as with IBM.

I've had lots of input from usenet about SRAM prices, etc., and I can
appreciate that there is no way to build a 33MHz 80386 PC with no wait
states 100% of the time without the price going to $50,000. 'Nuf said.

BUT my point is that the alleged "leaders" in the industry are not even
keeping up with what the small companies are doing. For example, the
Amiga doing 700-900KB/s "real" disk I/O. I've had this confirmed now
by several people, some who I know personally. And new PS/2s come out
with SCSI doing 200KB/s, at THREE TIMES the price of the Amiga. THEN
we have the $30,000 MIPS M120/5 only doing 600KB/sec, the AViiON
doing 300KB/sec, the Sparcstation doing 200KB/s, etc. etc.

So my belief is that some companies are trying to save I/O BW for their
*big iron* by purposefully handicapping the speed of their PCs. They 
accomplish two things: First, saving BW for the *big iron* by making
big databases run too slow, and second encourage hardware upgrades 
sooner by limiting your I/O so you'll need more hardware sooner.
And even though workstation vendors don' have *big iron*, they DO
have a $200,000 "high end" they NEED to sell which won't sell if their
entry level models do 1MB/sec disk I/O.

What I would like to see happen is for trade papers to place much more
emphasis on disk I/O so that the *big iron* PC makers will no longer be 
able to play this game with the consumer. Infoworld, PC Week, are you
listening? (Or are you going along with this because of all the advertising
dollars you are being paid?) At lease PCs are cheap enough that you can
buy & test them without signing a non-disclosure agreement!

Barry Traylor writes...
In article <7981@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:>
>>	Well, I just tried it on my machine (old, slower disk controller,
>>medium fast SCSI disk (Quantum)).  Read 3Meg file into memory: 609K/s.
>>Copy 3 meg file (on slightly fragged partition) to another file on the
>>same disk partition: ~550K/s.  On a newer controller with a fast SCSI disk
>>(170Meg CDC): ~900K/s and ~800K/s.
>
>Ok, ok, so we've now seen two pretty impressive transfer rates for MICROs.
>I would even go so far as to say that the rates reported beat by a little
>the PDP11/70 I used 10 years ago.  I hope, however, that you don't think
>this comes even close to what is attainable SUSTAINED on a mainframe.  

Hmmm.  I'm talking about sustained rates *per job*, not for the *system*. I know
overall throughput is in excess is 100MB/sec. But who makes a disk drive that
does 100MB/sec transfers? The best now is 3-4MB/sec. So when we get right
down to it, a COBOL program reading a file can expect less than 3-4MB/sec on
a mainframe. (The same reasoning explains how a 100 MIPS 4 processor mainframe
can only support 25 MIPS *per job*)

>much of the CPU was chewed up while these transfers were underway? 

If you are running single tasking OS (NOT UNIX), who cares? You have to
wait until the transfer is done anyway, so it might as well be as fast as 
possible. Hopefully SCSI does DMA while the CPU is busy elsewhere(comments
please..)

>I have seen mainframes do 50 times that rate (on a 1 processor system) and only
>utilize 10% of a CPU.  

Yup. That is because of intelligent channel processors that do DMA to multi-ported
memory. The same thing SCSI can do. Except with one user, we only need one channel
(or one for each file). But with UNIX we could use a few more.

>I have seen I/O rates at 4000-5000 i/os per second
>where the CPU is less than 75% utilized.  How many SCSI channels do these
>micros support? 

One I think. Comments others please!!!!!

>On a strict connectivity basis, the mainframe I am associated with can support 
>over 100!

But also they can support 1000's of users at once. Not needed on a PC.

>So go ahead and feed steroids to SCSI.  It will help mainframes as much as
>everyone else.  We would love to sell our mainframe customers hundreds of
>the things to squeeze into their pack farm acherage.

 I guess you aren't in marketing! MF vendors don't want to *encourage* users to
 port 500MB databases to micros, because the profit margin is so low on PCs.
 I believe they enact plans that discourage users from leaving the *big iron*, which
 would include limiting PC I/O to 300KB/sec. Look at IBM's OfficeVision - it's
 mainframe-centered.
 
I'm hoping some engineers might speak up who have actually designed PC disk I/O 
subsystems and could tell us why they didn't try for 900KB/sec like on the
Amiga.


Cliffhanger@cup.portal.com

-----