Benchmarks for Linux Applications on S/390 Zseries? 16
qaseem asks: "I am looking for benchmark results of various
applications (DB, WebAS, mail, etc.) on Linux on the S/390 mainframe.
I am also looking for tools to stress test these applications when
installed in the S/390 Linux partition. I was wondering if anyone has
seen such information or tried such tools. On a side note I am also
interested in finding a way to relate the MIPS speed of the S/390 to
the world of MHz or GHz on other platforms."
Unclear (Score:2)
Re:Unclear - Reply (Score:2, Informative)
Red Books (Score:4, Informative)
It is all about memory bandwidth... (Score:3, Interesting)
DB apps and the like should run nice and fast... makes sense... that is the reason S/390's still exist.
Re:It is all about memory bandwidth... (Score:3, Interesting)
Re:It is all about memory bandwidth... (Score:1)
Far from slow (Score:4, Informative)
Benchmarking a mainframe involves standalone use, which is rarely accessible except when performing a benchmark. It is analogous to single user operation on Linux. You cannot obtain a performance measurement in a multiuser environment. It's like trying to get Quake FPS numbers while there are 200 other users logged into your Linux machine, doing who knows what. You'd be lucky to get two measurements the same, and neither would be valid.
The mainframe instruction set also contains incredibly complex instructions, which are microcoded. The SIE (start interpretive execution) instruction is an example. This single instruction handles the execution of a virtual machine in it's own unique environment (this is what handles running multiple Linux virtual machines on the same mainframe). This makes the concept of "MIPS" and "MHz" completely meaningless.
As a result, benchmarks concentrate on throughput: transactions per seconds or workload executions per unit time.
Someone else mentioned the I/O system on mainframes. The architecture is somewhat analogous to using a PostScript printer, from the 22,000 mile view. The CPU writes a program (channel program; a collection of CCWs -- channel command words). It transfers that to one of the, possibly multiple, dedicated I/O CPUs called IOPs (I/O Processors) in the mainframe with a single instruction. These IOPs in turn transfer operations to the dozens to hundreds of device controllers (over 1-16 of the possibly hundreds of parallel ~OC3 speed I/O channels), which are small I/O computers outside the mainframe. The controllers in turn talk to the actual devices (up to 32 per controller). There can be (and frequently are) thousands of devices attached to the mainframe at once (disk drives, communications controllers, printers, tape drives, etc.).
All I/O operations are asynchronous and essentially DMA. Much of the I/O error recovery is performed by the IOP and controllers without intervention from the main CPUs. In addition, misbehaving devices can be identified and recovered independantly, or isolated from the system. There's no such thing (barring a now very rare bug) as a malfunctioning device causing a system failure.
Memory bandwidth is very high as has been mentioned, but it's also multiported, multiplying the bandwidth. That is, memory is read and written to concurrently by multiple CPUs and IOPs.
The ideal mainframe environment is one in which the CPUs are running at about 80-85% average CPU utilization, 7x24x365. Enough headroom for peaks, but well utilized. The elimination of all bottlenecks in the processing complex is a required requisite to achieve this state. It's the ultimate hardware hacker/overclockers dream machine.
Re:Far from slow (Score:3, Informative)
I have to disagree. Mainframe CPUs follow the same laws of physics as other computers. Yes they are build with good I/O in mind, and yes they have good memory bandwidth.
I disassembled a 5-MIPS machine last summer and discovered the CPU unit had a 60MHz clock chip (and a 55 and a 72 and a few others in that range) This would put a 60MIPS machine (the size a medium-size grocery store chain might use) at about 720MHz. Using a Pentium whatever at one end of the scale and your choice of High-end CPU at the other, and factoring in the good I/O, etc. it's hard to say that machine (about $180k + 20k/month in licensing fees) is going to be substantially faster than say a quad-900MHz 8GB RAM box from Sun for essentially the same price, or big box from Compaq (alpha), HP, and perhaps even a high end Intel-based machine.
What it _does_ do is run legacy business applications very well, and it runs reliably. So go ahead and use it -- just don't claim it's almost as fast as a supercomputer.
Going to the opposite extreme in Mainframe land -- multiple zSeries tied together in a Sysplex cluster running at thousands of MIPS -- sure that's a fast machine, but you just dropped $10million or more on the hardware and license fees would be well over a $million a year. You're then forced to compare once again to a (for example) 72-way Sparc system from SUN or any of the other high-end Unix systems out there, usually at about 1/5 to 1/10th the cost, and usually with minimal on-going licensing fees.
Re:Far from slow (Score:2)
Mainframe benchmarks are not performed like PC benchmarks; the idea it to completely remove (as much as possible) any constraint on the performance of the CPU (i.e., operate the CPU unconstrained). The measurement is solely the perform of the CPUs, and not the I/O subsystem.
The problem is that microcoded instructions operate like very complex instructions. It's somewhat like comparing CISC to RISC. In this case, the PC CPU (say, a P4) you are using as a base is actually the RISC CPU in the comparison.
MHz became very meaningless along time ago in the mainframe world. For a while, they had gone to adjusted MIPS (millions of instructions per second), based on an adjusted comparative value to an ancient mainframe. That fell apart about 15 years ago, and TPS (transactions per second; work per unit time) became the comparative measurement for judging the performance of a mainframe CPU. It's probably changed; I've been out of the field for 6+ years now.
If you wanted to compare a PC CPU like the P4 to a mainframe CPU, you would need to establish an "equal workload unit", then measure the number of workload units completed in a given interval by each processing complex operating unconstrained.
We spent 2 days just establishing and validating a baseline at the IBM Washington Systems complex for a benchmark about 10 years ago. It's not quite as simple as comparing the Mhz numbers.
Re:Far from slow (Score:1)
The mainframe instruction set also contains incredibly complex instructions, which are microcoded.
For example, the Move String (MVST) and Compare Logical String (CLST) instructions are the Standard C library functions strcpy() and strcmp() respectively.
Memory bandwidth is very high as has been mentioned, but it's also multiported, multiplying the bandwidth.
Not to mention up to 12-way SMP, with complete cache consistency!
Probably the wrong question... (Score:2, Interesting)
Re:Probably the wrong question... (Score:2, Interesting)
0.8 to 1 Mainframe MIPS for a Pentium 200.
10 Mainframe MIPS or more for a dual CPU gigahertz class Pentium-iii box.
IO Rates of 50 EXCP/second for an average PC disk I/O subsystem.
IO rates of over 500 EXCP/second for an average PC RAID array (hardware).
put these numbers and extrapolate to give you the mainframe equivalent to a PC.
Re:Probably the wrong question... (Score:2, Interesting)
Thanks