Since David asked.... - and i think we're mostly in agreement.... It is important to compare processor power when a single threaded task has a greater CPU requirement than a processor provides. Without naming names, if you have a single thread application that requires most of a processor to meet service level requirements - you do not want to put that application on a slower processor. But Capacity planning should be done for ALL resources - you have to have enough of all resources in order to meet service levels. By vertical scaling, if they mean that some servers are faster than one s/390 engine in terms of raw CPU, they are correct. If the application does a lot of I/O, then the power of the s/390 kicks in. If you want to run 100 applications, then an s/390 scales significantly better. What resource is less 'vertically scalable' on s/390? CPU, storage, I/O, concurrent applications? 'single engine speed' is not the only criteria to meeting service levels...
I'm betting that a very large percentage of the servers out there are suited for consolidating to s/390. I'd also bet that a great many pilot projects did not include capacity planning as part of the project. This can lead to resource intensive applications being ported. These may not be suitable for an environment where resources should be 'shared' between applications. Some applications are more suited to 'dedicated resource' environments. When sizing resource requirements for an existing application, you DO need to compare processor speeds. Do you need .1 IFL engines or 8 of them? the right answer is you need 'enough'.... >From: David Boyes <[EMAIL PROTECTED]> >> I am involved in discussions with some UNIX guys that insist >> Linux on s390 >> is not "vertically scalable". I need to get around this >> point. I have >> some questions. > >There is some truth to this assertion. Linux on S/390 does not do well where >solving the problem is gated on delivering volumes of raw CPU cycles to a >single instance of Linux -- the 390 CPUs are designed for balanced workloads >with lots of changes in workload and priorities, not raw compute power on >individual streams of instructions. Applications which expect this behavior >do not do well on 390. > >> How do we compare processor power between HP, Sun and IBM >> with relation to >> UNIX and Linux? > >In general, you don't, because it's comparing apples to kumquats. Different >tradeoffs were made in the designs of the processors, and comparing MIPS or >"processor power" just gets you into a black maze of "what is comparable >performance". The I/O system and operations cost are more interesting >discussions, especially as we start seeing a lot more convergence in I/O. I >favor looking at the outcome of the environment as a whole, including >management and personnel costs as metrics, as a better comparison of how >effective a solution is, but YMMV. Barton Robinson differs with me here, but >I'll let him explain his view, as he does a better job of it. > >-- db "If you can't measure it, I'm Just NOT interested!"(tm) /************************************************************/ Barton Robinson - CBW Internet: [EMAIL PROTECTED] Velocity Software, Inc Mailing Address: 196-D Castro Street P.O. Box 390640 Mountain View, CA 94041 Mountain View, CA 94039-0640 VM Performance Hotline: 650-964-8867 Fax: 650-964-9012 Web Page: WWW.VELOCITY-SOFTWARE.COM /************************************************************/
