> On Mon, 2007-04-09 at 23:52 -0600, Paul Gilmartin wrote: > > > > > > Not really. Since the *ix boxes max out at 30% utilization, you need > > > > > This statement has been repeated so often among mainframe > > partisans that it has come to be accepted without question. > > Can someone provide a source, attribution, citation, whatever?
And Shane said > I've no Unix background, merely Linux, but I'd be hard pressed to > believe this RoT (if it is such) is valid. > With respect to Linux, maybe it came from 2.4 kernel days - *lots* of > servers still appear to run this for "stability". > Maybe it came from 2.2. > > With 2.6 I'd be *real* surprised if you can't productively run the CPU > much harder - although I/O (including swap/page) traffic can be a bit > problematic at high rates. This is an old canard. Back in the day you would see pretty bad cpu (queuing) contention at 70-odd percent in UNIX systems that did lots of multitasking because there was no moral equivalent of SRM or WLM making effective choices about who was more deserving. UNIX had and still has a priority scheme but frankly its pretty lame. If you were comparing something like an MVS/TSO system with a UNIX box supporting similar interactive users the MVS/TSO box was always going to get more (transactional) work through - again, making no judgments about their relative utility. However... If you had an application that was essentially a single process that did repetitive things, then the OS didn't have a lot of work to do and so there wasn't much resource contention. You could run something like that as hard as it would go. And as Shane said, it would be things like paging or I/O that eventually limited throughput. It is no accident that the Win and Lin and *IX approach has always been more oriented to a single application per box. When you shape the world like that, you are not very likely to run into the sort of contention issues that SRM and WLM were designed to solve in a single system. This is a key difference - their universe looks different than ours and we have to be careful when making comparisons. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
