Re: PSI story
You have clarified your meaning of the word loss and I am a happy camper now. :-) So much for the Predator vs Chuckie movie script...8-)
Re: OT:I/O in Emulated Mainframes (Was Re: PSI story)
We share with the PC's - but OpenSystems DASD cannot be 'shared' with the Mainframe DASD. That essentialy means that all the open systems are on their own disk ranks. Our piggy old Exchange Server handles only a few hundred connected users, and still gets slower than slow. This is Exchange Server 2003, which is still 32 bit code, so that may change when and if we move to Exchange Server 2007 and 64bit code. That's on a four processor machine with plenty of RAM, and the DASD using dual connections to the Shark. -Paul ---BeginMessage--- --- Paul Raulerson [EMAIL PROTECTED] wrote: Hey Dave - (Also speaking for myself) I agree with you in part. But add 100 users to a PC and watch what happens to the IO. Or add a heavily used database with a few hundred users. PC Servers just do not scale in terms of I/O the same way. iSCSI and other technologies are starting to change that, but... -Paul I would like to disagree. Our busiest servers, i/o wise is our mail server. It normally runs around 1000 concurrent connected users. It does slow on busy days, such as the first day after a holiday period, when users have a few hundred e-mails to process. I did investiagate and found the bottle neck is either the SAN switches or the SAN proper. That is the same SAN and Switchs that the mainframe uses. The reason they slow is beacuse of the way the I/O is designed in the SAN, that is down to a price not up to an commited I/O bandwidth and throughput. We recently upgraded the SAN and saw a significant improvement in both Mainframe and PC operation. A quick question. Do users with Sharks dedicate them to their Mainframes? or share with PCs? From: Dave Wade [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Date: Thu, 1 Mar 2007 08:17:00 + Subject: OT:I/O in Emulated Mainframes (Was Re: PSI story) --- Jeff Gribbin, EDS [EMAIL PROTECTED] wrote: With a small amount of trepidation (but inviting stomping from anybody who feels that I'm off-base here) can I remind folk that, on IBM mainframe hardware, MIPS aren't the whole story. There's channels too - and in an I/O-related situation their power needs to be ADDED to the CPU power to come up with a realistic, comparative MIPS figure. It's a very long time since I saw anything that indicated how much MIPpage is offloaded into the channels by a typical, mainframe workload but please remember that, unless you understand how channels are implemented when comparing two different solutions, you can quickly mislead yourself regarding the genuine value of the, MIPS comparison. (I have a similar problem regarding, channel bandwidth - each individual channel on a mainframe might be, slow but potentially I can have several hundred running in parallel - in the right circumstances doesn't this give me greater capacity to work with than a single but much faster I/O portal? Do I want a firehose or do I want the Mississippi? As a man to whom I would happily defer when it comes to performance issues has occasionally been heard to comment, I think, It depends ...) Regards Jeff Gribbin (Speaking only for himself.) Jeff, Hercules runs channel emulation and CPU emulation in separate threads, so in a multi CPU box with say n CPUS, if you define m Mainframe CPU, n-m are generally (pedants note generally) free for channel emulation. However whilst I have never tried to do a real benchmark, I am firmly convinced that I/O is not an issue on a modern PC. To expand a little, I have tried a few simple things to drive the I/O system up and bottleneck the I/O in Hercules.. Sadly, every time, I have failed. I do keep trying, but I have never been able to justify adding RAID, SATA, or even SCSI (other than for tape) to the box I use for Hercules. When I look in PERFMON the i/o queue length and the i/o service times remain short. As I only emulate one CPU and have (kind of two) on the Hyperthreaded box, I see the second CPUs utilization remains low. I have therefore concluded that emulating S/370 channels does not tax the system. Again it might be different for the XA I/O system , but I don't think so. (In fact I think it may be simpler) Dave. Also speaking for himself. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited ---End Message---
Re: PSI story
grin You may be right Ed. Sometimes it feels like Second Start to the left and straight on till morning stuff. Difficult to believe, but IBM usually does right by their customers. -Paul ---BeginMessage--- To both Paul Raulerson and David Boyes. I believe that you are Preaching to the Choir. It is a loss. And some day Hercules may be supplied/support/allowed by IBM, but when small to medium companies switch it takes a long time for them to get the bad taste of what IBM did to us out of their mouths. Such is life! Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 ---End Message---
OT:I/O in Emulated Mainframes (Was Re: PSI story)
--- Jeff Gribbin, EDS [EMAIL PROTECTED] wrote: With a small amount of trepidation (but inviting stomping from anybody who feels that I'm off-base here) can I remind folk that, on IBM mainframe hardware, MIPS aren't the whole story. There's channels too - and in an I/O-related situation their power needs to be ADDED to the CPU power to come up with a realistic, comparative MIPS figure. It's a very long time since I saw anything that indicated how much MIPpage is offloaded into the channels by a typical, mainframe workload but please remember that, unless you understand how channels are implemented when comparing two different solutions, you can quickly mislead yourself regarding the genuine value of the, MIPS comparison. (I have a similar problem regarding, channel bandwidth - each individual channel on a mainframe might be, slow but potentially I can have several hundred running in parallel - in the right circumstances doesn't this give me greater capacity to work with than a single but much faster I/O portal? Do I want a firehose or do I want the Mississippi? As a man to whom I would happily defer when it comes to performance issues has occasionally been heard to comment, I think, It depends ...) Regards Jeff Gribbin (Speaking only for himself.) Jeff, Hercules runs channel emulation and CPU emulation in separate threads, so in a multi CPU box with say n CPUS, if you define m Mainframe CPU, n-m are generally (pedants note generally) free for channel emulation. However whilst I have never tried to do a real benchmark, I am firmly convinced that I/O is not an issue on a modern PC. To expand a little, I have tried a few simple things to drive the I/O system up and bottleneck the I/O in Hercules.. Sadly, every time, I have failed. I do keep trying, but I have never been able to justify adding RAID, SATA, or even SCSI (other than for tape) to the box I use for Hercules. When I look in PERFMON the i/o queue length and the i/o service times remain short. As I only emulate one CPU and have (kind of two) on the Hyperthreaded box, I see the second CPUs utilization remains low. I have therefore concluded that emulating S/370 channels does not tax the system. Again it might be different for the XA I/O system , but I don't think so. (In fact I think it may be simpler) Dave. Also speaking for himself. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: PSI story
--- Paul Raulerson [EMAIL PROTECTED] wrote: I see two problems with this story - one is they quoted Phil Payne, whose has some kind of vendetta against IBM going. (I suspect he lost money in an emulator solution) and two, His input is pretty small and pretty accurate. Even for us Mainframe Software costs are hefty... I object more to the spin on that; Mr. Payne has a way of taking facts and presenting them in such as way as to lead people down the path he wants them to follow, even to the point where people will draw erroneous conclusions based on insufficient and/or incomplete facts. In specific, sure traditional mainframe software costs are high. zIIPs, zAAPs, and ILF's can be used to mitigate that cost, and the best part? IBM is producing those speciality engines in direct response to use complaints about cost. While I am not saying that a 10 person windows shop shoudl run out and but a mainframe as a file and print server, a 10 person shop with a high end software product just might find that a mainframe would host their product better than any other machine in the world. (Or not - it all depends doesn't it?) I simlpy don't know what Mr. Payne's agenda is, except I know he has an agenda, and that agenda is not compatible with getting lower cost high quality IBM products out on the market. Especially emulators. Itanium hardware is faster and more modern than a mainframe PC, but ... it is not running Itanium software, it is emulationg the zSeries arch. How does this make it slower? The zArch is implemented largely with microcode (well, millicode perhaps) which servers to somewhat isolate the hardware of the machine from the processor instruction set it presents to software and programmers. An IBM processor (PC) is tuned to run that instruction set and does so very well indeed. There is also a lot of hardware stuff in a CP that helps too. Hint: the iSeries and pSeries (or whatever they are called these days) run POWER processors, which descend from and borrow from mainframe technology. NOT the zArch instruction set, but some of the underlying CP technology. An Itanium chip is not tuned to run that processor instruction set; it is by definition a General Purpose Digitial Processor. To emulate a MVI or LHI instruction on an emulator can require an order of magnitude more processing than on a CP (or IFL). For one thing, it has to emulate the GPRs, and may have to emulate the Access Registers and more. Then it has to reliable produce the correct results from exectution of the instruction. And those are two of the most simple instructions in the processor to emulate. The emulation may also be required to do things like run a 31bit OS under a 64bit OS - such as running OS390 under zVM or something. That is even before you beging to consider the subject of I/O. On a mainframe, I/O is usually handled by a SAP (System Assist Processor) which is nothing more of less than an entire CP. Also, each channel controller is smart, about the equivalent of a fast PC. Mainframes will usually loose out on raw processing power to the new generation of microchips - but they can move some I/O brother. There are not other GPDC machines around that move I/O like a mainframe. In short, additional overhead and a speed reduction is unavoidable when using emulation. Now, the Itanium processor is fast enough that slowdown may not be that much of a big deal. Again, it depends entirely upon the application set and the way the system will be used. Heck, anyone with a P4 running at a couple gig can build an emulated mainframe system that will clock in with a sustained 40 to 60 MIPS. It isn't legal to run anything other than Linux and some very old copies of VM and MVS on it, but it will run just about anything. That's on a X86 chip base. (BTW: Mentioning that to Mr. Payne will usually produce a strong reaction.) Anyway, point it, the article did not present the complexity and true situation very well, at least in my opinion. Your milage may vary. :) I'm not sure the authors of this article really get those ideas. :) -Paul From: Phil Smith III [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Date: Wed, 28 Feb 2007 13:17:00 + Subject: PSI story Interesting -- if not particularly accurate, at least in some areas I know about -- story about PSI and IBM: http://www.theregister.co.uk/2007/02/16/psi_ibm_hp/print.html ...phsiii
Re: OT:I/O in Emulated Mainframes (Was Re: PSI story)
--- Paul Raulerson [EMAIL PROTECTED] wrote: Hey Dave - (Also speaking for myself) I agree with you in part. But add 100 users to a PC and watch what happens to the IO. Or add a heavily used database with a few hundred users. PC Servers just do not scale in terms of I/O the same way. iSCSI and other technologies are starting to change that, but... -Paul I would like to disagree. Our busiest servers, i/o wise is our mail server. It normally runs around 1000 concurrent connected users. It does slow on busy days, such as the first day after a holiday period, when users have a few hundred e-mails to process. I did investiagate and found the bottle neck is either the SAN switches or the SAN proper. That is the same SAN and Switchs that the mainframe uses. The reason they slow is beacuse of the way the I/O is designed in the SAN, that is down to a price not up to an commited I/O bandwidth and throughput. We recently upgraded the SAN and saw a significant improvement in both Mainframe and PC operation. A quick question. Do users with Sharks dedicate them to their Mainframes? or share with PCs? From: Dave Wade [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Date: Thu, 1 Mar 2007 08:17:00 + Subject: OT:I/O in Emulated Mainframes (Was Re: PSI story) --- Jeff Gribbin, EDS [EMAIL PROTECTED] wrote: With a small amount of trepidation (but inviting stomping from anybody who feels that I'm off-base here) can I remind folk that, on IBM mainframe hardware, MIPS aren't the whole story. There's channels too - and in an I/O-related situation their power needs to be ADDED to the CPU power to come up with a realistic, comparative MIPS figure. It's a very long time since I saw anything that indicated how much MIPpage is offloaded into the channels by a typical, mainframe workload but please remember that, unless you understand how channels are implemented when comparing two different solutions, you can quickly mislead yourself regarding the genuine value of the, MIPS comparison. (I have a similar problem regarding, channel bandwidth - each individual channel on a mainframe might be, slow but potentially I can have several hundred running in parallel - in the right circumstances doesn't this give me greater capacity to work with than a single but much faster I/O portal? Do I want a firehose or do I want the Mississippi? As a man to whom I would happily defer when it comes to performance issues has occasionally been heard to comment, I think, It depends ...) Regards Jeff Gribbin (Speaking only for himself.) Jeff, Hercules runs channel emulation and CPU emulation in separate threads, so in a multi CPU box with say n CPUS, if you define m Mainframe CPU, n-m are generally (pedants note generally) free for channel emulation. However whilst I have never tried to do a real benchmark, I am firmly convinced that I/O is not an issue on a modern PC. To expand a little, I have tried a few simple things to drive the I/O system up and bottleneck the I/O in Hercules.. Sadly, every time, I have failed. I do keep trying, but I have never been able to justify adding RAID, SATA, or even SCSI (other than for tape) to the box I use for Hercules. When I look in PERFMON the i/o queue length and the i/o service times remain short. As I only emulate one CPU and have (kind of two) on the Hyperthreaded box, I see the second CPUs utilization remains low. I have therefore concluded that emulating S/370 channels does not tax the system. Again it might be different for the XA I/O system , but I don't think so. (In fact I think it may be simpler) Dave. Also speaking for himself. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
Re: PSI story
With the loss of the Flex 64-bit capability for general use Sorry to nitpick, but I don't believe there has ever been a FLEX 64-bit capability for general use. I'd say that the unavailability of the 64 bit FLEX *is* the loss I'm talking about. On this list (and others), we've been discussing the problems between FSI and IBM on public release of the 64 bit FLEX for months. It will not see the light of day for general customers due to IBM and FSI being unable to come to an agreement. We've seen Cornerstone and T3 present different sides of the case, and you have also responded to the discussion. I call that inability to find common ground a loss. It's an obvious loss to FSI who did follow the rules and tried to work it out with IBM, for obvious reasons. It's a loss to IBM for people who a) don't have the space for a z9, b) don't have the environmentals for a z9, and c) can't afford a z9. IBM is losing, and will continue to lose unless there is a different approach from System z marketing, those small to medium Z customers -- not to the z9 BC, pSeries or iSeries, but to *other vendors* who can deliver a solution that doesn't require a lot of renovation. Ultimately, the loser is the poor schmuck at the customer who's stuck with having to cope with the switch when some finance bozo cuts off the funding for a working solution because it would require renovating the machine room. IBM certainly has the RD capability to out-innovate these upstarts -- the patent IP that seems to be the point of the PSI discussion makes it clear that there's plenty more brains at IBM than elsewhere. The question is how quickly it can be transformed into *something people want to buy*. Clearly there's a desire for a solution in this space that IBM is not providing. How long can IBM afford to bleed small customers that eventually might grow up to be bigger customers -- but have already switched to competing technology? That's really the open question. The current marketing strategy is killing your pipeline of new workload. (We won't raise the general dumbness of the current software marketing campaigns, although it's hardly helping the story...) IMHO, it comes down to the statement that if you can keep a small customer on z until they *are* bigger, then it becomes an inertial decision to STAY on z. The longer you keep them, the harder it is to switch either to -- or from -- System z. So, call it what you will. Loss suits me.
Re: PSI story
Well, just my $0.02, and I have no inside knowledge at all... But... My guess is IBM is doing it's level (and legal) best to get out from under encumbering agreements, and will sooner or later, embrace Hercules as the platform of choice for Sub 200 mips Mainframe platforms. Yep - Hercules. There are no downsides to this from IBM's point of view - they only license mainframe software, such as z/OS, to IBM branded hardware and they build in a hardware dongle to make sure. They can of course do exactly that, since the source code is open and there is no restriction on how you use Hercules that would apply. They simply *do not charge for Hercules*. If and when they do so, it is a great financial advantage to everyone, and they may just open up and restructe the PWD program to be very much more cost effective to developers. At least, that is the pattern IBM seems to follow - every time a PWD program dies off, there is a better one to replace at less cost and with more functionality to the user. (Except for the innumerable an annoying times the website is redesigned. That just keeps getting worse, in my no so humble opinion.) Anyways, it could happen. :) -Paul ---BeginMessage--- With the loss of the Flex 64-bit capability for general use Sorry to nitpick, but I don't believe there has ever been a FLEX 64-bit capability for general use. I'd say that the unavailability of the 64 bit FLEX *is* the loss I'm talking about. On this list (and others), we've been discussing the problems between FSI and IBM on public release of the 64 bit FLEX for months. It will not see the light of day for general customers due to IBM and FSI being unable to come to an agreement. We've seen Cornerstone and T3 present different sides of the case, and you have also responded to the discussion. I call that inability to find common ground a loss. It's an obvious loss to FSI who did follow the rules and tried to work it out with IBM, for obvious reasons. It's a loss to IBM for people who a) don't have the space for a z9, b) don't have the environmentals for a z9, and c) can't afford a z9. IBM is losing, and will continue to lose unless there is a different approach from System z marketing, those small to medium Z customers -- not to the z9 BC, pSeries or iSeries, but to *other vendors* who can deliver a solution that doesn't require a lot of renovation. Ultimately, the loser is the poor schmuck at the customer who's stuck with having to cope with the switch when some finance bozo cuts off the funding for a working solution because it would require renovating the machine room. IBM certainly has the RD capability to out-innovate these upstarts -- the patent IP that seems to be the point of the PSI discussion makes it clear that there's plenty more brains at IBM than elsewhere. The question is how quickly it can be transformed into *something people want to buy*. Clearly there's a desire for a solution in this space that IBM is not providing. How long can IBM afford to bleed small customers that eventually might grow up to be bigger customers -- but have already switched to competing technology? That's really the open question. The current marketing strategy is killing your pipeline of new workload. (We won't raise the general dumbness of the current software marketing campaigns, although it's hardly helping the story...) IMHO, it comes down to the statement that if you can keep a small customer on z until they *are* bigger, then it becomes an inertial decision to STAY on z. The longer you keep them, the harder it is to switch either to -- or from -- System z. So, call it what you will. Loss suits me. ---End Message---
Re: PSI story
To both Paul Raulerson and David Boyes. I believe that you are Preaching to the Choir. It is a loss. And some day Hercules may be supplied/support/allowed by IBM, but when small to medium companies switch it takes a long time for them to get the bad taste of what IBM did to us out of their mouths. Such is life! Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441
Re: PSI story
I believe that you are Preaching to the Choir. Very possibly. On the other hand, you guys write bigger checks to IBM than I do. There are also some quiet people lurking on this list that do have the ear of senior IBMers -- and others -- in ways that I don't. Don't kid yourself -- HP and Sun folks read this list closely. but when small to medium companies switch it takes a long time for them to get the bad taste of what IBM did to us out of their mouths. Judging by the continuing reaction to the DECsystem 10 and 20 cancellation and IBM's failed SNA-will-take-over-the-world networking strategy, we've got a long wait coming. HP is *still* paying for DEC cancelling Jupiter way back in 1982, even two companies later.
Re: PSI story
On Thursday, 03/01/2007 at 02:16 EST, David Boyes [EMAIL PROTECTED] wrote: With the loss of the Flex 64-bit capability for general use Sorry to nitpick, but I don't believe there has ever been a FLEX 64-bit capability for general use. I'd say that the unavailability of the 64 bit FLEX *is* the loss I'm talking about. I just wanted it clear that 64-bit FLEX is not now, and has never been, available for general use. To the uninitiated your statement was ambiguous. You have clarified your meaning of the word loss and I am a happy camper now. :-) Alan Altmark z/VM Development IBM Endicott
PSI story
Interesting -- if not particularly accurate, at least in some areas I know about -- story about PSI and IBM: http://www.theregister.co.uk/2007/02/16/psi_ibm_hp/print.html ...phsiii
Re: PSI story
I see two problems with this story - one is they quoted Phil Payne, whose has some kind of vendetta against IBM going. (I suspect he lost money in an emulator solution) and two, Itanium hardware is faster and more modern than a mainframe PC, but ... it is not running Itanium software, it is emulationg the zSeries arch. I'm not sure the authors of this article really get those ideas. :) -Paul ---BeginMessage--- Interesting -- if not particularly accurate, at least in some areas I know about -- story about PSI and IBM: http://www.theregister.co.uk/2007/02/16/psi_ibm_hp/print.html ...phsiii ---End Message---
Re: PSI story
--- Paul Raulerson [EMAIL PROTECTED] wrote: I see two problems with this story - one is they quoted Phil Payne, whose has some kind of vendetta against IBM going. (I suspect he lost money in an emulator solution) and two, His input is pretty small and pretty accurate. Even for us Mainframe Software costs are hefty... Itanium hardware is faster and more modern than a mainframe PC, but ... it is not running Itanium software, it is emulationg the zSeries arch. How does this make it slower? I'm not sure the authors of this article really get those ideas. :) -Paul From: Phil Smith III [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Date: Wed, 28 Feb 2007 13:17:00 + Subject: PSI story Interesting -- if not particularly accurate, at least in some areas I know about -- story about PSI and IBM: http://www.theregister.co.uk/2007/02/16/psi_ibm_hp/print.html ...phsiii Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
Re: PSI story
I see two problems with this story - one is they quoted Phil Payne, whose has some kind of vendetta against IBM going. (I suspect he lost money in an emulator solution) and two, His input is pretty small and pretty accurate. Even for us Mainframe Software costs are hefty... I think I'd agree in this case. While Phil is often unnecessarily caustic, the emperor's new clothes occasionally ARE invisible, and no one else is willing to stand up and say it. Phil often serves that function. Even with the recent price drops for hardware and software, IBM *is* pricing System z out of the low and midrange market (considering only new equipment). With the loss of the Flex 64-bit capability for general use, and now the loss of the emulated PSI solution (whether or not it violates IBM patents I don't know), there's not a compelling solution commercially available that competes with the more high-end Opteron and Itanium commodity systems. With HP providing VMS on Itanium, there's a serious alternative to z/OS available and viable again, and one that provides a lot more MIPS for a lot fewer dollars with few compromises in security (and a lot easier manageability and serviceability. Any mouth-breather can manage VMS semi-competently -- generations of grad students have proven that over and over. )If HP plays it's cards right, they could take a serious chunk of the small z/OS and VSE markets away from both zSeries and iSeries, without customers sacrificing security and/or reliability. VMS clustering isn't parallel sysplex, but how many sites short of the high-end *need* sysplex? Itanium hardware is faster and more modern than a mainframe PC, but ... it is not running Itanium software, it is emulationg the zSeries arch. How does this make it slower? Another interesting argument. If the basic assumption is that the emulated zArch performance is proportional to the underlying Itanium performance, there's a lot of things that could be compelling here. Certainly Hercules seems to do an awful lot in this area, and the argument for Core Duos and Opterons seems to track Moore's Law closely.
Re: PSI story
... it is not running Itanium software, it is emulationg the zSeries arch. How does this make it slower? Another interesting argument. If the basic assumption is that the emulated zArch performance is proportional to the underlying Itanium performance, there's a lot of things that could be compelling here. Having not seen the CPU its hard to say what is going on, but the PSI blurb implied that they were using changed microcode and Just-In-Time tecniques to speed up emulation. Certainly Hercules seems to do an awful lot in this area, and the argument for Core Duos and Opterons seems to track Moore's Law closely. I can't really judge. I understand the mainframe at work (and I forget the model) is rated at about 70 mips. When emulating normal 370 mode, with Hercules, running VM/370R6, I get about 28 mips out out of a hyper-threaded 3ghz Pentium. I know its slower when emulating 64 bit, but from this it seems that Emulation could easily provide that level of performace on a 4-core box. (either 2 x 2 core or 1 x dual core). No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail
Re: PSI story
On Wednesday, 02/28/2007 at 04:43 EST, David Boyes [EMAIL PROTECTED] wrote: With the loss of the Flex 64-bit capability for general use Sorry to nitpick, but I don't believe there has ever been a FLEX 64-bit capability for general use. Alan Altmark z/VM Development IBM Endicott
Re: PSI story
With a small amount of trepidation (but inviting stomping from anybody wh o feels that I'm off-base here) can I remind folk that, on IBM mainframe hardware, MIPS aren't the whole story. There's channels too - and in an I/O-related situation their power needs to be ADDED to the CPU power to come up with a realistic, comparative MIPS figure. It's a very long time since I saw anything that indicated how much MIPpag e is offloaded into the channels by a typical, mainframe workload but please remember that, unless you understand how channels are implemented when comparing two different solutions, you can quickly mislead yourself regarding the genuine value of the, MIPS comparison. (I have a similar problem regarding, channel bandwidth - each individua l channel on a mainframe might be, slow but potentially I can have severa l hundred running in parallel - in the right circumstances doesn't this giv e me greater capacity to work with than a single but much faster I/O portal ? Do I want a firehose or do I want the Mississippi? As a man to whom I would happily defer when it comes to performance issues has occasionally been heard to comment, I think, It depends ...) Regards Jeff Gribbin (Speaking only for himself.)
