I just IPL'ed the S/390 Sunday 2/9/03 it was up since we installed our new MP3000 1/9/02 that's January 9, 2002. I IPLed to install Z/VM 4.3.0 (Scheduled Change)
> -----Original Message----- > From: Ken Dreger [SMTP:[EMAIL PROTECTED]] > Sent: Friday, February 14, 2003 4:45 PM > To: [EMAIL PROTECTED] > Subject: Re: URGENT! really low performance. A related question... > > Robert, you are buying into the thought that the PC is mans best friend in > the Business world..... > > Let me ask you, how many times during the day do your PC users re-boot ? > then tell us how many times you IPLED your s390 system, (that crashed and > burned, not because of scheduled changes) in the last year ??? And then > tell us how many users your s390 supports daily, without a single > complaint.... No Blue screens of death...... > sorry, the PC folks just don't get it.... and until they experience in > person a Live & well mainframe...they won't get it.... in their minds the > PC runs circles around the Mainframe..... And in some cases it does !!, > but for the 99.999999 other % of the work the mainframe is the Energizer > Bunny !!!!!! > > > Just had to get that off my chest, since it is Friday..... > > > Ken Dreger > > > > At 03:32 PM 2/14/2003 -0600, you wrote: > >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 > > > > > > > > > > Kenneth G. Dreger > Un-employed and seeking position as > Sr. IBM Systems Programmer > Consultant in OS390, z/OS Systems, > Linux 390 systems, Web page consulting, > High Tech Investigations > Home pages: http://ken.dreger.com > Our Santa site: www.acornartists.com > The PI site: www.laprivateeye.com > The CAPI site: http://californiaprivateinvestigators.org > My RedHat system for Linux (s390) downloads > http://kendreger.homeftp.net > Contracting services available at reasonable rates > Contact: [EMAIL PROTECTED]
