There's also the fact that your cheapo-cheapo PC has one processor and has to do all 
the I/O for itself.  The PC's processor spends 90% of its time handling I/O, 
formatting data for some port or the screen, running a driver program, polling and 
waiting for a response from some peripheral and so on.

Mainframes hand the I/O off to the I/O subsystem processor, which hands it off to the 
channel processors (Last I heard, an ESCON channel used the same processor chip as the 
Macintosh, but that's been a while) which hands it off to the controller for the 
device.  You've got a lot of processors working for you, and everything's cached along 
the way so you may not even be doing any real I/O half the time.  The point is, the 
central processor has very little to do with any I/O processing.

Someone once told me that my 9672-R36 with three processors at 117 mips each should, 
with all the I/O processors, actually be rated at around 30,000 mips.

But that 30,000 is for I/O only,  the other 351 mips are for computing only.   Use the 
right tool for the job at hand.  Don't try to use a pair of pliers for a wrench.

They say there are three signs of stress in your life.  You eat too much junk food, 
you drive too fast and you veg out in front of the TV.  Who are they kidding?  That 
sounds like a perfect day to me!
Gordon Wolfe, Ph.D. (425)865-5940
VM & Linux Servers and Storage, The Boeing Company

> ----------
> From:         Phil Payne
> Reply To:     Linux on 390 Port
> Sent:         Friday, February 14, 2003 7:59 AM
> To:   [EMAIL PROTECTED]
> Subject:      Re: URGENT! really low performance. A related question...
> 
> > Speeding up the mainframe machines to at least match the toy machines would really 
>make our
> jobs a lot easier when we're trying to sell the mainframe concept.
> 
> I think you're trying to sell the wrong thing.
> 
> The first time I hit this was back in the mid-1970s.  We'd designed a mainframe IMS 
>database
> to run FORTRAN transactions against time series economic data for financial 
>modelling, and
> justified a 370/158 as the host.  Our capacity plan gave us a staged growth pattern 
>and
> upgrades were planned.
> 
> All of a sudden our curve died and CPU usage plummeted - so we convened a meeting.  
>It turned
> out they'd bought a raft of Hewlett-Packard technical calculators and were running 
>their
> "what-ifs" on those.  When they got close, they'd go back to the mainframe.  They 
>could each
> load their personal 3KB or so of data and play for hours.  These were the early LED 
>display
> devices, so you HAD to have the mains power plugged in!
> 
> It's always been the way.  Mainframes have NEVER stacked up as cheap sources of 
>compute power,
> and were only used for that purpose when the problem was too big for any other 
>approach.
> 
> You have to concentrate on the mainframe's unique selling propositions.  In the 
>Linux world,
> for instance, the speed with which a new server can be created and the ease with 
>which it can
> be managed.  Show that as a cost-of-ownership advantage, and the comparatively huge 
>extra cost
> of mainframe MIPS is so small as an absolute quantity that it almost gets lost in 
>the rounding
> errors.
> 
> But get yourself cornered into instructions-per-transaction or some other wholly 
>artificial
> benchmark and you've lost before you begin.
> 
> --
>   Phil Payne
>   http://www.isham-research.com
>   +44 7785 302 803
>   +49 173 6242039
> 
> 

Reply via email to