Related Topics: CMS Journal

CMS: Article

Readers react to 'Weighing the pros & cons of IBM's mainframe Linux'

Readers react to 'Weighing the pros & cons of IBM's mainframe Linux'

Good news about UTS

The article contains a reference to Amdahl's mid-1980s UTS product and asked if anyone knew what happened to it since. Seems it's alive and well:

Dear Mr. Murphy,

UTS is very much alive and kicking. Check out our Web page at: http://www.utsglobal.com

We are not a part of Amdahl and haven't been for about two years.

UTS is still very much in use, check out our customer list. You'll find some very large customers. Our market is chiefly oriented around the telecommunications industry.

UTS Global is also active in the Linux/390 community. We've contributed 3270 support to Linux/390 2.4, and have released CLAW and tape drivers under the UTS Global Public License.

Dennis Andrews
Chief Software Architect
UTS Global LLC

Ignorant, incompetent, untrustworthy, and dishonest

Three things in Part 1 triggered the most response:

  1. My comments about the history of VM.
  2. My comments about the use of assembler.
  3. My comments about paging in VM when trying to create 41,400 instances.

Two VM experts who reviewed the paper before publication warned me about all three. In retrospect, I wish I'd been smart enough to listen to them.

Paging

I was dead wrong on paging. I had forgotten about VM's use of re-entrant code in which all of the guests running share the same code image.

This raises other issues and reinforces my belief that all 41,400 images were essentially identical and shared everything while doing nothing but the ascription of paging needs was certainly stupid on my part.

Not only was this wrong, but the mistake buried the main point: The issue is not running 41,400 copies of something. The issue is if those 41,400 images do "real work." If they do nothing, independence isn't an issue, and there's no need for an external network connection. The problem is that third parties, not IBM or David Boyes, are interpreting this experiment as proof positive that you can take 41,400 real x86 Linux servers, virtualize them on a single two-way mainframe with 128 megabytes of RAM, and get the same level of service you started with.

This is nonsense; it's just as if I reported that I can start 10,000 "sleep 7200" processes on a Model 80 (true) and other people then ran around claiming this proves its ability to serve 10,000 concurrent users.

Sendmail's benchmark

We've had considerable discussions with the Sendmail folks. As part of this they've done a full mstone report on tests on using the z900. Originally, Sendmail said we could publish data from this and would provide a pointer to where you could download the document yourself to check it and then sent us an email saying that all of the information is confidential.

Pending a full and careful review of the document and their permission to release data from it, I can say that it looks okay but you need to be aware that the claim that a z900 can support 2 or 3 million e-mail users, if in fact supported by the data, applies to very low volume POP3 users on dial-up modem lines. The more realistic IMAP numbers drop by three orders of magnitude -- from millions to thousands.

If you check the mstone report on similar tests run against a Dell 733-MHz machine with Red Hat 6.2, you'll see a very different ratio. On the Dell, the test showed that 3,000 IMAP users can be supported on the same gear that runs about 15,000 nominal POP3 users; on the mainframe, the numbers we have put that ratio closer to 25:1.

If, or when, Sendmail releases the data, I'll put a follow-up analysis here or on my Web site.

C vs. Assembler

Many people insist that most of zOS is now C, that assembler no longer has a key role, and/or that PL/X isn't "close to the hardware." This entire argument misses my point.

I'm not saying assembler is always faster than C, that PL/x is better than C, or that applications are generally coded in either assembler or PL/x. I'm saying that using assembler to debottleneck applications is:

  1. Common practice for mainframers but not for Unix users.
  2. Very effective.
  3. Part of a 40-year tradition of debugging that has led to the achievement of high levels of optimization on system libraries and other OS-related facilities.
  4. A contributing cause of the mainframe's ability to run at high throughput rates whose benefits go away when you run Linux on that mainframe.

History

On the history of VM, the overwhelming majority of comments are simple ad hominem attacks.

In my opinion, however, these people are responding more to my failure to subscribe to core community beliefs than in defense of the validity of those beliefs. I'm sorry to offend, but just insisting on allegiance to commonly accepted Truth only illustrates the role of that acceptance as a touchstone for membership in the community of believers. It does not amount to actual evidence for the validity of the belief.

If you are interested in a humorous (well, tragicomic) version of the early history take a look at this spoof. It's bitterly funny, and close enough to reality that its not obvious whether the authors intended those of us who had to live with this stuff to laugh or cry.

Shilling for Sun

I do not work for Sun and I do not sell Sun products. I do, however, use Sun gear personally and generally recommend it to consulting clients because it meets my No. 1 criterion for computer systems: it works essentially all the time.

Note to Scott McNealy
I may not be in Sun's pocket, but I'm not above pondering bribery. Do you need someone to review that 20th anniversary workstation? My wife has a 20th Anniversary Mac I'd be happy to compare it to -- but, remember, anything less than 2.1-GHz, 8 gigabytes of RAM, a 24-inch LCD, and 4 x 73-gigabyte hard disks and that Mac will turn out to be prettier, faster, better...

In the article, I try to compare to Linux on x86 whenever possible but the combination of IBM's apparent focus on replacing Sun, not Linux, servers and the relative scale of the mainframe forced a lot of Sun comparisons too. So far, no one has come forward with comparable PA-RISC and/or Alpha numbers, but I think that when I do get them, they won't be much different from Sun's numbers.

It works! It saves heaps of real money!

Yes, Linux on the mainframe works pretty well. Technically, it's very cool. However, we do not have data to support the notion it's as widely applicable as people claim. Nor do we have benchmark results to suggest it is cost or performance competitive with conventional Unix-hardware combinations, whether that's Linux on x86, Solaris on SPARC, HP-UX on PA-RISC, Tru-64 on Alpha, AIX on Power4, or another combination.

Those who wrote to me about cost savings hammered at sunk costs. Their argument is, "Organizations that already have a mainframe can use it virtually cost-free to run Linux applications." Unfortunately, this logic exemplifies something known as the sunk cost fallacy.

The sunk cost fallacy is a big thing in behavioral economics and finance. Behaviorally, it's usually an attempt to recoup already spent dollars by spending more dollars. Technically, it's a failure to limit decision-making considerations to the costs and benefits of the current decision by including consideration of monies already committed or benefit already earned. Check for "sunk cost fallacy" in Google and you'll find many examples.

A case in point is the eWeek story Linux on Big Iron on mainframe Linux cited in the first article. The story does not give enough information to make a final judgment about what happened but clearly points to people who think they "saved heaps" of money using Linux on the mainframe to run 700 e-mail accounts at a cost of $26,000 plus at least 7 percent of the mainframe's processor capacity.

I think a real investigation would show that these people tripped over the sunk cost fallacy to create what amounts to an IT management version of "America's Funniest Videos." The kind of thing in which people get hurt on camera and we all laugh because it isn't us -- check this Slashdot thread for the laughter and then take a good look at that story while asking yourself about the likely total costs to the business owners.

Batch v. interactive

A number of people see my characterization of the mainframe hardware environment as batch-oriented instead of interactive as terribly wrong. Well, so did IBM's Joann Duguid and this is clearly an issue of serious importance to the VM community. This is another case where I wish I'd said it differently. However, I maintain the correctness of the basic argument: This hardware is highly optimized for batch throughout, not delivery of interactive user services.

In response to the gentleman who commented:

He obviously has never used CMS on VM, it's as interactive and responsive as any Linux system I've used.

was forwarded to me by a third party, I have a question: Are you saying you used a GUI like CDE, GNOME, or KDE with CMS or that you've never used Linux?

Deep Throats and other future friends

I received some interesting, but not confirmed, information on costs and performance claims made by IBM salespeople. In brief, total costs are said to be higher than those cited in the article, and claims include things like replacing 7,000 two-way Linux servers with one four-way mainframe. We asked IBM to confirm the authenticity of one of these documents and will report further.

Various people have contributed the results of running simple benchmarks like Bonnie++ on mainframe Linux.

Here are some sample results:

 Sequential OutputSequential InputRandom Seeks
Per ChrBlockRewritePer ChrBlock
MachineSizeK/sec%CPUK/sec%CPUK/sec%CPUK/sec%CPUK/sec%CPU/sec%CPU
IBM Mainframe184M2153991479014356272311989846097859.410
IBM Mainframe256M133499900143450610134799994510433.86
1.4-GHz Athlon4G1684292217931470584165408127016978.20
Sun UE2 (Dual)1G43417411605356318295387971963837355.710
Note: The "UE2" test was run using a Sun Ultra Enterprise 2 with two 167-MHz UltraSparcs and the original 7200-RPM, 4.2-GB disks it came with in 1997. This is the workstation cited by Sine Nominee in its anlysis of replacing 500 UE2s and 270 Enterprise 1000s with one mainframe.
Those are the two best results submitted so far for mainframe Linux.

More Stories By Paul Murphy

Paul Murphy wrote and published 'The Unix Guide to Defenestration'. Murphy is a 20-year veteran of the IT consulting industry.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.