Mainframes, IFL, and Linux

Summary:Since both SPARC and x86 servers are considerably cheaper even than the p550Q, the question to ask isn't whether you can run Linux on the mainframe, but whether you can get the 92.5% discount you'll need from both IBM and Novell for this to make sense

(Note: This is a re-run - from May 16, 2006) The IFL, or integrated facility for Linux, is a mainframe CPU license that's limited to running Linux. Novel has yet to post SuSe licensing costs for the new z9 series mainframes, but charged $13,999 per year per "processing engine" on the previous generation z900 series. in other words, if the same pricing held, you'd pay them about $750,000 per year for Linux on a fully configured z9. The actual performance offered by Linux on zSeries is secret. IBM only benchmarks the mainframe against itself and doesn't release absolute performance information about Linux (or anything else) in this environment. As a result what little published information exists tends to be less than totally credible. For example, the most recent third party analysis with real detail available on the web appears to have been done on Microsoft's behalf. Not surprisingly, this study found that a typical 900Mhz PIII running Windows outpeforms a z900 IFL by about 14%. Four years ago, when I first looked at this issue, there was quite a lot of IBM and third party performance data for Linux on the mainframe - all of which made Linux on the then brand new z900 series seem about on par with Linux on a low end PIII. Today IBM tells us only that performance on the z9 series can exceed that of the previous generation by up to 50% or more - but places where you'd expect to find real performance information, like the mainframe Linux tuning tips collection, appear to have been carefully sanitized for customer protection to provide no clues about performance relative to other environments. Look, however, at the primary repository for mainframe Linux community forums and what you see is an endless parade of self-cheering along with performance or installation related issues that rather clearly illuminate both the community and the reality of achieved performance. Consider, for example, both the numbers and the technical sophistication in this starter question for a May 9th thread about poor FTP transfer rates
We are running Linux guests on an IFL running z/VM I have two Linux (both SuSE 9) guests defined to the VSWITCH I have a 684MB file I use FTP to transfer the file from zLINUX1 to zLINUX2 Results:
1st ftp - 684MB in 2:47 (3.8MB/s)
2nd ftp - 684MB in 1:34 (6.88MB/s)
First question, why is the transfer better on the 2nd ftp of the file? Then, I attempt the same file transfer from one of my zLinux guests to an Intel platform Linux server (also SuSE9) on the network (outside of the IFL). I use the same 684MB file and use FTP to transfer the file from zLINUX1 to x86Linux Results:
1st ftp - 684MB in 1:11 (9.17MB/s)
2nd ftp - 684MB in 1:05 (9.96MB/s)
Biggest question, why is the transfer better going out the OSA adapter on the network? I certainly thought the transfer between two guests on the VSWITCH would have at least been equal if not better??
Regular forum followers should know what hardware this result reflects, but the only certainties for us come from looking at the question itself and the fact that performance on the external connection is significantly below that achievable between two PCs Running Windows 98 on Celerons. The true believers, of course, claim that performance is wonderful - but if so, why would IBM feel the need to hide the numbers? Get past the believer's attitude that you're either in the data processing community or an ignorant enemy of all things good and right and you hear one real response and two subsidiary ones. The real argument is that mainframe operational methods are so different from those used in the PC/Unix world that data processing's standards of performance measurement apply only within data processing - and by extension that the measures used by Unix and PC people simply don't apply. In other words, asking about transactions completions, or web pages served, per second is so fundamentaly wrong that they don't need to glorify the question by answering it. Among the many things wrong with this kind of response is the fact that if the mainfame is being used to run Linux, then surely Linux performance measures should apply. The two subsidiary arguments boil down to the claim that both mainframe I/O and mainframe processing are so superior to PC and Unix capabilities that comparisons are pointless. The I/O part of this reflects the mainframe's historical role in data processing from the days when a terabyte of storage required 9,400 disks and, ultimately, therefore the notion that real work consists of a record level read, modify, write cycle repeated millions of times. This is, or was, in fact correct: no standard Intel or SPARC machine offers 1024 independent SCSI channels or the ability to run a virtual OS and batch against each one independently. Unfortunately for this argument, however, the world has changed. These days companies like LaCie will ship you two 500GB FC or Firewire drives in one enclosure for use with a Mac laptop - and every modern system uses DMA from the controller in place of the mainframe's Storage Assist Processor. As a result the z9's ability to control well over two thousand disk I/O channels is meaningless given that the overwhelming majority of these are limited to SCSI era ESCON and 1st generation fiber channel products. Note that IBM does offer modern 4GB/S FC options for use with the z9 STI card case, but they add significantly to cost and multiples have to be throttled back to avoid flooding the device. Bottom line? Having thousands of small I/O channels gives the mainframe an advantage for legacy code running against legacy disk under legacy controls - but is of no value to mainframe Linux, or any other application, running with modern controllers against modern disk. The CPU argument is subject to the same kind of response. There was truth to this in the days when mainframes uniquely offered advanced, busines oriented, CPUs, fast memory, and near SMP across more than two processors. Today, however, a Power5+ is a Power5+, whether its in a mainframe or pSeries and there's no reason to believe that a four CPU, eight core, P550Q at 1.9Ghz won't out-perform its 1.65Ghz mainframe cousin on Linux tasks fitting within the 8-core SMP limit. The bottom line here is that belief in the mainframe's superior speed implies a belief in magic: the I/O argument applies only to legacy code on older, smaller, disk; the CPU efficiency argument has no basis; and the management and software argument doesn't apply if both the mainframe its pSeries cousin are running Linux applications. As I pointed out yesterday, a $22.5 million dollar check will get you either a Z9 (2096-754) with 54 effective processing cores at 1.65Ghz and 512GB of memory or about $20 million in change and a four rack cluster made up of 64 IBM p550Q machines offering a collective 256 cores at 1.9Ghz, 1024GB of RAM and 9TB of disk. Since both SPARC and x86 servers are considerably cheaper even than the p550Q, the question to ask isn't whether you can run Linux on the mainframe, but whether you can get the 92.5% discount you'll need from both IBM and Novell for this to make sense.

Topics: Linux, Hardware, Open Source

About

Originally a Math/Physics graduate who couldn't cut it in his own field, Paul Murphy (a pseudonym) became an IT consultant specializing in Unix and related technologies after a stint working for a DARPA contractor programming in Fortran and APL. Since then he's worked in both systems management and consulting for a range of employers inc... Full Bio

zdnet_core.socialButton.googleLabel Contact Disclosure

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.