When IBM first approached us about Linux/390 and an IFL, one of the first applications mentioned was print serving. Should be a fairly I/O bound task with lots of free time, right? Well we found out that on our print servers, serving our 15,000 printers, there's very little idle time to be had, making print serving a completely compute-bound limited task. So the comparison between the current print servers and Linux/390 was a disaster, and the Unix people here never went any further. The whole trial died on the vine, at least for them, right at the first print server test.
In any case, my point is, why do the mainframe CPUs *have* to be soooooo slow? Why can't they be beefed up to the point that they're at least ball park competitive, so that things like our trial don't happen? Why can't they be beefed up so that instead of having to buy a five way processor to do our work, we could get a two or three way, and spend less cash? If the separation of CPU and I/O computing is so great, then wouldn't it just be greater if the CPU portion could keep up with a PC? Or even see the PC's tail at the end of the race? Is separation of CPU and I/O processing really that important, when the PC toys can do both computing and I/O in their single CPU, faster than we can on our separated computing and I/O CPUs? I'm having a really hard time selling the concept to people here. You say that the PC spends 90% of its CPU time on I/O tasks.... If that's really true, then we're really in trouble, because it spends only 10% of its CPU power on the task at hand, and still has double the throughput of a single-IFL mainframe when both are dedicated to serving printers. And that is the statistic that we're trying to fight against here. I know the whole "I/O is separated" story; But I'm just tired of being laughed at by the Intel-minded people in the Unix and NT world here. ---- Robert P. Nix internet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 RO-CE-8-857 page: 507-270-1182 200 First St. SW Rochester, MN 55905 ---- "Codito, Ergo Sum" "In theory, theory and practice are the same, but in practice, theory and practice are different." > -----Original Message----- > From: Wolfe, Gordon W [SMTP:[EMAIL PROTECTED]] > Sent: Friday, February 14, 2003 11:16 AM > To: [EMAIL PROTECTED] > Subject: Re: URGENT! really low performance. A related question... > > 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 > > > >
