Slashdot Mirror
Year of the Mainframe? Not Quite, Say Linux Grids
OSS_ilation writes "IBM touted 2006 as a resurgence year for the mainframe, but not so fast. At R.L. Polk and Co., one of the oldest automobile analytics firms in the U.S., an aging mainframe couldn't cut it, so the IT staff looked elsewhere. Their search led to a grid computing environment — more specifically, a grid computing environment running Linux on more than 120 Dell servers. The mainframe's still there, apparently, but after an internal comparison showed the Linux grid outperforming the mainframe by 70% with a 65% reduction in hardware costs, Polk seemed content banishing the big box to a dark, lonely corner for more medial tasks."
FTFS: "Polk seemed content banishing the big box to a dark, lonely corner for more medial tasks."
Medial tasks? I think you mean menial tasks. Although there are such things as medial equations in algebra, I believe, but I don't think you were referring to those.
I hate to go into grammar police mode, but it bugs me when people misunderstand the usage of common phrases by replacing one or more words with another. I have actually heard people say "for all intensive purposes," hahaha. (as opposed to "for all intents and purposes"). And then there are all the weird expressions we do use, that are redundant or just make no sense: hot water heater, end result, safe haven, advance warning, vin number, atm machine.
I am Jack's complete lack of surprise.
As an admittedly non-initiate in linux (I run osx), this seems very much what linux is
good for, rather than for a desktop os, where difficulty of setup would be a severe
handicap. I've always believed that open-source suffers from the in-house-tool
mentality, which assumes the end user is extremely sophistacted. As an engineer,
I can testify to my lack of desire to make the UI more than bare-bones.
Maxim
So a NEW system outperforms an OLD system. I fail to see how this is a news.
If they had compared a NEW mainframe with the NEW grid, then we would have been able to draw some conclusions about which one is better. But saying "We bought a new system, its better than the old one" proves nothing.
It seems like a tall order to replace a 20 year old mainframe with a 118 CPU Linux grid... after all, rewriting millions of lines of code, testing, and transitioning both your IT and user workforce from Mainframe to something totally different ain't no small task. And that says nothing of any licensed products that may have been on the mainframe.
Interesting that someone did it, but I'd think each shop is it's own special case. I know it'd cost a huge chunk of change in my shop - to huge.
Everybody knows that low-cost x86 hardware en masse can easily outperform high-end solutions. Imagine a Beowulf cluster of those... ;)
So a brand new grid beat out a 20 year old mainframe. At a computationally-intensive task. I'm shocked.
The mainframe is many years old and they only managed to beat it by up to 70% with 120 machines? Either that thing is awesome or they suck with their grid.
You use the mainframe when you want error recovery at every step of the way. One of them even runs two CPU pipelines in lockstep so that a failing CPU can be safely isolated without crashing the app that was running on it.
The mainframe also gives you nice IO and super-efficient virtualization.
Workload doesn't need all that? Gee, maybe it's not a workload for the mainframe.
a 2066-002 is midway up the 'Baby Freeway' z800 mainframe line. It has 2 CP's and benchmarks 1.0-1.2x the performance of a 9672-R36 itself a 4-5 year old model in the middle of the pack.
the consulting group or whomwever spun up the new project wanted a paticular result so they aimed for it.
Most likely they didn't know how to program the mainframe to get the results they wanted but they did know how to use the solution they came up with
or
they knew how to do the mainframe side to the fullest potential of the machine but that wasn't cool enough so they redefined what good results were.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
what we need is "multiframes"
Consider an virual operating system, that can run on one or more other operating systems. This operating system is actually a set of nodes, one node per machine (or one node per CPU), with command nodes and worker nodes.
Command nodes distribute the workload and exist for redundancy. If one goes down, all others have a backup of it's data and state, and the next most senior node takes over.
Worker nodes then take the tasks and interface with the users via a standard shell.
Files can be distributed amongst the nodes for speed and redundancy, and if a node that needs a file doesn't have it, ant can request the file and temporarily have it locally. Each node will have a list of what files exist, and where they exist.
UI tasks are written to run solely on the machine of the user, but data crunching tasks are written to be split between nodes.
Thus, a person just goes to his or her machine, and interacts with it like a normal machine, except, rather than having a logon for his machine, he or she will have a logon for the multiframe.
Also, because of this setup, a multifram could work on top of multiple operating systems (say an office that is 50% windows for the normal users, and then 35% Linux for the devs, 10% FreeBSD for other devs, 5% HPUX/Sun for some server, and all machines coudl contribute to the multiframe.
The multifram could also have recorded statistics of uptimes and drops for various nodes, performance statistics for load balancing, etc.
The caveat to this system is that it would need some pretty heavy networking, even if optimised, and there could be latency issues. Still, I like this idea better than a mainframe.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
It sounds like a Linux grid is an excellent solution here - however, it also sounds like their software is not exactly performing perfectly:
This was especially the case when the IT staff had to accommodate new business requirements such as a car dealership adding a new type of vehicle to its inventory. Each update required a major rework of the program
Really?
Frankly that sounds like the software is in severe need of reworking! If their machines are 20 years old that's bad enough, but if they have 20 year-old software that needs to be rewritten every time a new type of car is added, it's time for a redesign.
This would be called a Linux cluster or Beowulf surely. Thats basically what they do...
Check out OSCAR or ROCKs clustering software. Run them inside vmware and your done.
ahh, ok, I'll have to look to see if BSD has something similar. My experiences administrating Linux has been less than pleasing.
So, do apps have to be written speciall for it?
I.E: an interface app is called, and it splits the work load up, and sends it to sub-apps on the various nodes?
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
As others have pointed out, the comment left a great deal out.
For example, any mainframe that can be replaced by 120 PC compute nodes isn't well utilized and/or is completely outmoded.
I had a chat with a gentleman once who participated in a replacement of multiple PC servers with a mainframe--but it entailed replacing 7,000 servers with a relatively high-end machine.
The result was that power and real estate savings alone paid for the mainframe--which had more capacity for future expansion as needed.
As always, proper implementation of the right equipment for the job is always crucial--and a shallow analysis that doesn't cover all the variables is simply misleading at best.
I'm trying to look them up right now, my other question is, can they run on an extremely hetrogenous network (i.e. multiple processor architechtures, multiple system performance speeds/data-storage size, and multiple operating systems all on the same network as base nodes?)
The idea is that instead of a company buying a $50k server, it can instead use the $50k of desktops it has for it's employees to be the server, saving them all of that money, and potentially giving them better performance, redundancy, stability and IO.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
How easy is it to install Photoshop on Linux? MS Office? iTunes? Logic? Vienna Symphonic Instruments?
Okay, so if I don't want to use the most popular online music store, never google for a tutorial on how to accomplish ___ with my graphics tools, don't like books, and don't need to exchange files with people who work for a living, there's always GIMP, OO and some programmerware media app I could use, and why would I want to compose music for orchestra on my computer?
Aboeba maybe?
"Update you skill set and get out of the way of progress"
Update your brain and start to understand that replacing one unique computer with 30 of them is not progress....it's just because it cost less....
Not quite. The idea would be that
Matt and Mindy in marketing use Windows.
Fred and Francine in Financial Management use VMS on their little alpha workstations (they are old fashioned).
Dan and Donna in development use Linux,
while
David and Denise in development use BSD
Now, Oscar and Oliva in operations use the mainfram (accessing it through their windows boxes).
What they don't know is that their mainframe is actually a distributed operating system running on Matt's, Mindy's, Fred's, Francine's, Dan's, Donna's, David's, Denise's, and their machines, just using up the spare cycles and splitting the data.
any compiled tasks (C, C++, D, etc) have to be compiled separately for each arch, true, though scripted (python, ruby, perl, etc) only need to be compiled once. All the spare CPU power is utlized.
It's kindof like TFA, except that it can be integrated into any architecture, and that mainframe would still be ustilized in mainstream work.
Basically the users would actually run "splitter programs", which would split the tasks, then send commands to the OS. The OS would then split these commands amongst the nodes as it sees fit, the commands themsevles would do all the processing.
It seems complex at first, but it's basically modular programming with the "splitter program" being the interface, and the logic control segment (except much of the logic control is handled by the OS saving time and effort), and the commands are the calculating programs. Some control programs (like the compression example) would simply be passthroughs and have no actual logic except to take the command, spit out progress reports, and say "done".
It would not neces to change the entire operating system, though some programs would require varying levels of rewrites, and most programs would require some amount of network programming.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
You can have intermediate results, and then ultimately an end result.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
This is sort of what we've been looking at for a while. We have a Linux grid, and there's a project now to hook our mainframe, running Linux, into it. The work units are all Java, so the biggest headache has been to get the vendors to port the parts of the management software that are in C.
So..... every end users desktop, no matter what applications they are running at the time, is also responsible for the mainframe application?
Maybe you can add some reliability with hardware partitioning, but that doesn't sound like an efficient solution at all.
PC desktops are not as energy efficient as servers, so what happens when 50% of the employees turn off their workstations at night?
IBM zSeries also have two execution units in each processor unit which execute in lockstep. If results are different the processor repeats the execution. If failure continues the processor will defer the instructions to another processor unit and disable the failing processor unit. This reliability, superior I/O throughput, and a tried-and-tested system is the advantage of the mainframe.
So instead of an OS/hardware loc, you have an application-environment lock (java). My thought is to get rid of even that.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
the energy efficiency is a good point, so there are a lot of factors that go into it, I agree. In this cas, at night you might loose roughly 50% of your computing power.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
IBM are also heavily investing in Grids, particularly with their support of the Globus Alliance Toolkit (see http://www.globus.org/)
Crazy? No, they are aiming at different targets. Mainframes are controlled by individual companies, grids are hoped to eventually be the equivalent of TCP - ubiquitous, reliable and cheaply available everywhere. That means your next Windows Vista T1000, Ubuntu Beam-me-up (TM) and self-aware toaster will seamlessly provide services to allow you to participate in grid-like problems just like any appliance. No more downloading the google toolbar to help cancer research, another app for cracking encryption, another app for predicting weather and so on...
---
Some algorithms are not parallelizable. For all those algorithms you want a single processor that can run as fast as possible. Clusters are no better than a single machine from the cluster. I assume that some kind of mainframe is the way to go. Any comments?
It sounds to me like a mainframe is still probably the best fit for this organization. Few solutions can match the efficiency, streamlined-goodness of an IBM mainframe. Where I work, a city government, we run two fairly beefy iSeries (AS/400s), one that runs accounting, utility billing and operation, and income tax operations, and another that runs public safety operations. I love them. No down time - ours are brought down about once a year, and usually that is because the power is out and our generators are about to run out of juice. Hands down the most stress-free aspect of our operation. That alone is worth something. The users also love it for the most part. While IBM's client access can be intimidating for most users at first (text!?!? what is this, the 70's?), once they adjust to it they tend to love how quickly one can skate through repetitive tasks. Nevertheless, it is not for everyone. If you don't have tons of data that needs to be reliably and efficiently accessed all day everyday, then you're probably better off going elsewhere. If anything, because most users, who can barely log in to windows reliably, find client access to be something of a magic black box that they cannot begin to comprehend (my favorite help desk call: "can you flip the magic switch for me?"). At the same time, I've seen the same users who can still barely operate a mouse, open a AS/400 session and go to town like a computer virtuoso. I guess what I'm trying to say is, IBM mainframe solutions definitely have their ups and downs, but for the right applications, they are irreplaceable.
"In God we trust, all others we monitor." -- Unofficial NSA motto
I posted my comment specifcally to get you Linux advocates interested.
So, now that you're here, why should I abandon osx for linux, specifically?
"It's not as hard to use as it used to be" needs to be improved upon, wouldn't
you agree?
Forgive me if I'm not up on the latest jargon, but what's the difference between a grid and a cluster?
Mainframes are not only bought for performance, but for the whole framework they have.
Mainframes have great ways to execute batch-jobs which most Linux systems still lack.
Linux just seems to be more suitable for near realtime things like desktop computers or workstations, perhaps smaller servers like Google uses them.
So essentially it doesn't matter if there are clusters of smallers computers cheaper and more powerfull than mainframes, mainframes still will be sold.
[i]It would be intresting to see exactly what the cost to implement a new lameframe system with equivalent performance would cost. ANybody got some rough numbers?[/i]
That's kind of like asking "how much would a brand new 386 system cost to replace this old 386?".
According to my mainframe hardware charts, my company still has a 2066, which we use for an extremely low-volume business unit. The 2066-02 is pushing 10 years old, uses a 2 engine CPU complex (think SMP), and has a processing power rating of ~77 MIPS. For comparison, our standard box is a 2084 with an 8 engine complex, and a power rating of ~1600 MIPS.
Think of it this way; if someone told you they'd replaced a 386 with a handful of Palm pilots, would you really be impressed?
- Despite popular opinion, I am not perfect.
... a long time ago, in a galaxy ...
I was a vendor SE who had occasion to visit R. L. Polk. There are customers who are "bleeding edge" customers, always looking for ways that the latest and greatest technology can give them an advantage in their business operations, and there are customers who are "junkyard" customers, who see everything as an expense, and only have the cheapest, oldest junk on the floors in their data centers.
Cost is the only metric for such customers, of whom R. L. Polk was one such (a long time ago, and it's possible that they have changed, but I doubt it, as it takes tremendous capital investment to dig oneself out of that sort of hole, and that's exactly the thing that these sort of companies will simply *not* do).
Given that as ancient hardware decays, the maintenance costs soar, I'm not surprised that a "junkyard" operation would find that aging mainframes are better replaced by a room full of PCs. But as to the performance improvements, I suspect that most of the credit there goes to the rewrite of the old mainframe apps written in COBOL, PL/I and assembler -- and if they had performed a rewrite in place, the observed performance improvements would have occurred on the mainframe as well.
This is a recurring problem with evaluating many of the mainframe-to-PC conversions. In the process of converting to run in the new environment, application programs that are several decades old benefit enormously from the rewrite necessary to operate in the new environment. The fact that they were converting assembler programs tells you something about the age of their software base. The fact that they were converting COBOL tells you something about the likely efficiency of their software.
Linux is an operating system. Mainframes are complete hardware solutions, which, by the way, can run Linux better than nearly any other hardware setup. I/O on a mainframe is probably the biggest advantage it has over any other solution, and will continue to have, because IBM has been refining it for 40 years.
As for the knocks on COBOL, write some non-trivial solutions with it and get back to me. You'll change your tune, I'm sure. I've written BASIC, COBOL, C, C++, Assembler for 390s and x86, Java, and a bucketful of scripting language solutions. The COBOL apps all crushed the other 3GLs simply because you can't beat an Amdahl mainframe for running through 16 million records each night during a production run. The COBOL compilers from IBM are probably the best compilers in the business, again benefiting from something like 35 years of refinement.
But hey, go out and buy 30 servers. Patch them, power them, rack them, cool them. Manage that. Meanwhile, the mainframe will stay up and running. Much more job security for me, and I'm still 15 years from retirement.
-BA
As is this post, I'd rate it at 0 myself if I had the power, mod away I can take it, but a rebuttal that makes you feel uncomfortable is not the same thing as a troll.
KFG
Yes I remember ALSA Hell which is especially true if your hardware is relatively new... Once I had to "buy" OSS drivers for a desktop as I could not get the recommended ALSA drivers to work. For wireless though the easiest method is to just connect the desktop/laptop to to a wireless bridge via ethernet.
After that, it's finding the suitable players, codecs, etc., so you can listen / watch streaming audio/video. Then comes the installation of 3D graphics drivers which usually also needs to be re-installed (same as ALSA) whenever the kernel needs to be patched for bugs/vulnerabilities.
IMHO, Linux for desktop/laptop is not ready for non-geek types who are not willing to spend extra time and effort to configure their machines.
Not only is it an apples and oranges comparison between an old mainframe and a new custom-built grid, but the software was completely different.
According to this the original software was probably poorly designed:
> the mainframe took on the persona of a lumbering behemoth. This was especially the case when the IT staff had to accommodate new
> business requirements such as a car dealership adding a new type of vehicle to its inventory. Each update required a
> major rework of the program
Hmmm, massive software reworks to handle new vehicles types? Yikes.
And who knows what the author of the article meant by this:
> Isiminger said his IT staff moved from the mainframe to a grid using high-performance code developed in Assembler and PL/1,
> business logic in COBOL, proprietary mainframe development tools, flat file processing, VSAM and some IMS.
Most of the above actually sounds like what would be running on the mainframe.
In any event, it sounds like the your typical scenario - the data requirements grew wildly beyond what was originally envisioned and designed for. The new solution (both hardware and software) were designed for a far larger amount of data.
The more interesting question now is how well would a new mainframe compare?
- initial cost: mainframes can be hand for as little as $100k, and may cost less than 50 dual-cpu dell servers
- labor cost: one mainframe is most likely cheaper to support than 50 servers - especially when you consider requirement for absolute consistency between the 50
- adaptability: the grid has some benefits here with easy additions and subtractions from the gird - but grid performance relies upon problems that can be easily partitioned. The mainframe has extremely mature virtualization - easily allowing new lpars (separate hosts) to be created and managed without so much of the overhead of pc based virtualization products.
We still have a 2066 in our shop. According to my power charts, the 2066 rates approximately 77 MIPS. If the Dells are giving a 70% performance increase, that means roughly 130 MIPS, or 1.1 MIPS per server.
In comparison, our standard model mainframe (a 2084) kicks up about 1600 MPS. Assuming the performance numbers for the Dell grid were to scale (the safe money says it doesn't), that translates into almost 1450 Dells. Keep in mind, that's not even a top of the line mainframe...
Let's not even start on hardware maintenance (which would you rather do: hot swap a power supply on 1 system, or 25?), network overhead, shared DASD, coupling facilities and RRS (think: Beowulf clusters).
- Despite popular opinion, I am not perfect.
I agree with you, except for the GP's comment about wireless. Linux and wireless just don't work together, unless you're lucky enough to have one of the few well-supported chipsets (thankfully some of the ones used in laptops are OK, e.g. Centrino). But if you go down to Best Buy and pick up a random Wifi card and expect it to work, welcome to the house of pain. If you're lucky, they'll be a driver for it (like the acx100/111 series), but you'll need to find and download the right firmware...there's no "plug and play." Plug-n-pray, possibly -- because you're praying that the vendor hasn't changed the chipset on you, from whenever the card model was last reported as working with your distro, praying the firmware you downloaded works, pouring over dmesg's output trying to figure out what hotplug is up to, praying you wrote the config files right because the GUI tools are about as helpful as a screen door on a submarine...it makes me somewhat ill just thinking about it.
Personally, I've given up on wifi on my Linux machines. I'd rather just get a few thousand feet of Ethernet cable and a cordless drill and start boring holes, because at least that's a tractable problem. (Although it's been pointed out elsewhere that future Ethernet drivers may have the same issues as current wifi cards, because they're all ditching EEPROMs and Flash for driver-loaded, non-distributable firmware.)
Now granted, wireless on Windows isn't necessarily any picnic. The vendor-supplied drivers are often complete pieces of shit and buggy as hell. I spent three hours trying to get WPA-PSK working on a flatmate's WinXP system once, because of the crap D-Link calls drivers. I wouldn't want to expose a novice computer user to that. But I was able to get it working, and I'm not really an experienced Windows user (use one at work but don't own one and don't plan to); everything about Windows makes my brain ache. As much as I would really like to say that Windows is vastly inferior to Linux in every possible way, it's just not true, at least where wireless is concerned.
There is only one platform which makes wireless easy enough to use that I would trust a novice user to set it up, and that's the Apple's. There's a lot Apple does wrong, but you can't criticize how they handle wifi on the Mac. If you want wireless, you go to your Apple Store and buy the card. It costs a lot of money, but it's guaranteed to work, no dicking around.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Polk: Mainframe, we're gonna need to go ahead and move you downstairs into storage B. We have some new people coming in, and we need all the space we can get. So if you could just go ahead and pack up your stuff and move it down there, that would be terrific, mmm-K?
IBM 2066-002 Mainframe: Excuse me, I believe you have my stapler...
mod me funny
- There's no central control over resources.
- System uses open standards.
- System provides non-trivial quality of service.
Here, at least the first point is not fulfilled. So yes, they've built a cluster. A cluster like hundreds of others, used since the early 90s. It's 2007, isn't it? I'm impressed!IBM has had this for years. I was called the RS/6000 SP2. Great system. They have since replaced it with the Cluster1600 and with BlueGene/L Look at the top500 http://www.top500.org/ and you'll see they're up there.
-Aaron
The post made with 100% recycled electrons
One objective benchmark to consider when comparing clusters vs. a server or mainframe is the TPC-C online transaction processing benchmark. http://tpc.org/tpcc/results/tpcc_perf_results.asp? resulttype=all Clusters get beat here in both absolute performance and performance/price, with the first cluster in the top ten being a cluster of 4-way HP Itanium servers. Granted this benchmark may or may not be relevant to what you care about, but it is definitely a very clear objective test for online transaction processing.
It really depends on what your workload is and what you are trying to accomplish. I've seen Linux on the mainframe be a horrible thing and I've seen it be a pretty cool thing that worked wonderfully. If you are trying to do heavy math processing on a mainframe then it probably won't get you the bang for your money. On the other hand, heavy IO will probably work very well. You also get the benefit of being able to run hundreds (or even thousands) of Linux guests on one single server. That conserves physical space, electricity, software license costs, and the hardware is extremely reliable (which is part of the reason it is so expensive). It also makes disaster recovery much more straight forward.
Even IBM will tell you that there are some applications that you should not run on a zSeries processor. I've been in meetings where IBM has said that some types of workload will not perform well on a zSeries processor and you should consider Intel or some other platform.
There is no "one size fits all". Anyone who says there is "one size" is probably selling something.
From the article:
And what of that old mainframe? It's still around, but Isiminger wouldn't say exactly what it was up to. It operates in a "reduced capacity," he said.
LOL... anyone else think they just created a HTTP server farm to frontend the data, using WebSphere, MQSeries, and/or DB2 Universal as the backend (all still running on the mainframe)?
- Despite popular opinion, I am not perfect.
The caveat to this system is that it would need some pretty heavy networking, even if optimised, and there could be latency issues. Still, I like this idea better than a mainframe.
And this caveat kills the deal. The problem has always been that networks simply can't compete with the throughput of native devices. Consider this:
Yeah, a multiframe is a nice idea, but it just doesn't work for the IO intensive workloads of business.
And the interesting thing is that it will always be this way. The maximum throughput of a bus is inversely related to the length of the conduit. The internal busses of computers, whose max length is typically measured in centimeters, and typically have 16,32, or 64 data lines, will always be able to outperform the network type busses. For example, USB has one "data line". Ethernet has 4. EIDE has 16, and PCI 32. It comes down to a simple matter of math and physics, and no amount of technological progress will change this.
The society for a thought-free internet welcomes you.
It shuold be possible to guessimate the cost of a machine that has the equivalent processing power of the grid that was implemented, although it most most likely need to be done by someone directly involved with the project, I suppose. I wasn't actually trolling in the GP, I would actually like to see some sort of a cost comparison.
Perhaps the parent here can help me out with a question I've always wondered about as well. The 2084 machine mentioned is described as having about 1700 MIPS. A rough estimate of one of the new P4 processors is about 7000 MIPS. It's CISC as well, but in reality, I'm assuming the 2084 would have better overall computational throughput. Is this because of i/o bandwidth, or is MIPS just a very inaccurate measurement?
Also, what is the rough cist of a 2084?
uh, IBM has this in the 70s, VM/370
Comparing a Linux grid system with a mainframe is comparing apples and oranges. The mainframe's strength has never been raw computing power. Mainframes have practically zero downtime and massive I/O capabilities. If you can swap a Linux array in for a mainframe and have results this good, you were using the mainframe for a task to which it wasn't suited to begin with.
"The problem with internet quotations is that many are not genuine" -Abraham Lincoln
I'd like to see what the difference there is.
"Also, what is the rough cost of a 2084?" The cheapest option is a tad over a million dollars. Here is a break down of the cost of the various flavors of the 2084. http://www.tech-news.com/publib/pl2084.html
Unfortunately, I'm just a technician; I leave the dollar amounts and funny money dealings to the lower lifeforms (a.k.a. MBAs).
- Despite popular opinion, I am not perfect.
I know Grid is the buzzword of the day, but this isn't a grid. It's a cluster, or perhaps a beowulf, but it is not a grid. Buying a bunch of identical boxes and installing identical software on them doesn't make a grid.
One of the key features of a grid is that it "coordinates features that are not subject to centralized control". (What Is The Grid, Ian Foster, ANL). Grids by definition cross organizational or management boundaries. You can't buy a grid any more than you can buy an Internet. You can buy a network. You can buy a cluster. You can't buy a grid.
While I refer to the numbers as MIPS, technically, on mainframes they're called zMIPS, or kMIPS (kilo-million instructions per second). Therefore,
77 (mainframe) MIPS = 77 (IBM) zMIPS = 77000 (x86) MIPS
My apologies for not being clearer.
- Despite popular opinion, I am not perfect.
Note also that those are the purchase prices, not the lease price.
- Despite popular opinion, I am not perfect.
> "IBM touted 2006 as a resurgence year for the mainframe"
I heard vinyl albums made a comeback last year, too. Evidently people love the nostalgia of it all.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
But even if such a study showed that XP "just worked" more often than Ubuntu (which I personally suspect to be the case), the two would still be in the same ballpark. So the claim that Linux distros are "not ready" for the desktop is just not true. There may be differences in the "just works" batting average for non-techies, but you have a good chance of it "just working" with any modern Linux distro or XP.
The real clincher, however, is that you have an almost %100 chance of everything "just working" if you buy a preinstalled system. These are available for linux distros as well as the ubiquitos XP. Unlike with XP, linux distros actually have a choice of software vendors for preinstalls.
I _did_ find IBM Announces Five Year March to Mainframe Simplification, which is quite different:
Everyone here talks about comparing an aging mainframe with lots of new Dells. Surely enough the Dells tend to beat the old mainframe hands down. It's not only about performance it's cost/benefit relation that is interesting.
What is wrong is saying that a new model "9999 PLUS HYPER SUPER" could beat those 120 Dells to the floor anytime. Sure they can but they cost like 1200 Dells during the same period. That's what we need to calculate before doing anything. The article says that to go to a NEW mainframe would cost so much more than the grid AND would still keep is less flexible. I'm OK with that wording, it's the reality I see.
I've seen grids like this (100+ blade PCs) swipe the floor with some very new models of the mainframes costing ridiculosuly more. I'm talking 5 to 10 times less price for the PCs to do the same job. It all depends on what you want to do but a well designed application can take a grid to the stars. A bad designed one (Polk one really looks very bad) may just work or be slower than an aging mainframe. And a 120 node grid surely can beat that aging mainframe orders of magnitude more than a 70% improvement.
That said, mainframes have their place. For big batch like jobs it's the winner hands down. It was created to be like that. I believe online/realtime processing is not their primary job but in some cases can be too. Reliability? Wins hands down too, for each processor you have a mirror one that calculates the same thing and compares the results to map out faulty processors. It's desinged to run 24/7/365 and normally suceeds doing that.
But you can achieve a similar kind of reliability with grids because of redundancy of the nodes. There is no problem that one of those nodes breaks, you always have more than one doing the same job. Performance may suffer for a while when it's a small number of nodes doing that job but you can eventually replace it and everything keeps going. A grid CAN run 24/7/365 easier than a mainframe cause you can selectively stop some nodes, replace or repair it and restart it without affecting the entire system. Using this strategy you can even replace everything from the hardware to the software without stop (stop half of the nodes, change everythind needed, restart them, stop other half and do the same). It's more difficult to do that on a mainframe.
I still need to be show that the cost/benefit of a mainframe surpasses a grid except in very limited cases. Maybe I'm just misinformed. I would like to learn more.
No real substance.
Could even be a failure being spun to look like a success- I mean look at this:
"And what of that old mainframe? It's still around, but Isiminger wouldn't say exactly what it was up to. It operates in a "reduced capacity," he said"
"reduced capacity", that smells like BS talk. Does that mean it's still doing some of its old tasks, or most of its old tasks?
Of course they might not want to get rid of the mainframe that they paid so much money for (though there is a market for 2nd hand mainframes), but basically you can't always believe these Press Releases.
I also find it hard to get impressed that a cluster of 49 _new_ machines with 118 processors is only 70% faster and 65% cheaper than a mainframe that was available in early 2002. Plus that mainframe might even still be used to help the cluster to achieve those rates!
Next thing - how much more reliable and available is that cluster?
From the bullshit that was printed, I'm actually less inclined to think it was that huge a success.
But more details would be needed before I'd be sure whether they actually screwed up majorly, or did passably, or it was actually a big success (yeah right).
You should be at +5 already, as your detailed and insightful answer is a perfect refute to TFA in general as well as to grandparent.
To nitpick, one minor detail: IIRC, Ethernet has only one data line too, but it's duplex. (So Cat5 sports a total of four wires for a twisted-pair cable both ways.)
"Life on the grid also saved money. Millions, to be precise. Isiminger's IT group now operates at a 43% smaller size, and the move away from the mainframe to a grid computing model reduced hardware costs by 65% overall."
At first notice I thought this meant they were able to layoff 57% of their staff (100%-43%), but then maybe that 43% is a 57% reduction in total budget accounted for by the 65% overall reduction in hardware costs.
I have kinda been following the whole Mainframe thing for a while, and the best way I can summarize the presented dichotomy is to ask you to consider an IBM Z-series (as opposed to other "mainframe" hardware) as an Elephant. Note that IBM marketing once revered to the IBM Z-990 as the T-Rex, another good animal allegory, yet I digress...
:^).
What is interesting is the I/O capability of that damn Elephant. The sucker is built to process data and never forget a thing. For years the Elephant only spoke Elephant language. A few years ago the boys at IBM Boeblingen taught the Elephant to speak Penguin. That makes the whole story interesting...
Now out in the Data Processing Jungle they are two types of animals, the fast and the dead. The good news is that all the real fast animals all speak Penguin. To make the fastest creatures in the Jungle, St. Don Becker and his buddies at NASA built a flock of Super Penguins. These are the mightiest beasts in Data Processing, but they have sort of horrible I/O limits (if you want to consider FIOS data rates horrible
So I have always wondered why not harness the Elephant to do what is does best; plod along in the I/O and never forget.
Finally, the Elephants by their philosophy and architecture have one VERY important quality, they are not typically hacked. IMHO, the Elephant is a mighty beast capable of great I/O and when correctly bred and reared, flawless security. Why not use this large Elephant (or Dinosaur as per IBM) to protect, feed and water your precious flock?
Just a thought....
Flint
This was the year of the mainframe...
-ubuntu others as you would have others ubuntu you.
There is no reference to the increased floorspace, and increased cooling requirements of their new setup. Raised floor space and the cooling requirements of many indivdual servers would increase much more than the reduced hardware costs...do the reduced hardware costs include the additional air conditioners? lol
I used to admin 500 linux servers on a single mainframe LPAR. There were two other people involved in VM and Network configuration. There was ONE refrigerator sized piece of hardware. Kind of curious what the 43% of IT group they trimmed out were doing...
Sounds like the real problem was the initial environment was designed poorly....but its hard to tell because its so short on info. How many CP's did their mainframe have? Was the mainframe 20 years old? What model? This just stinks of FUD...
Granted Mainframes aren't cheap...but they are as reliable as hell...you get what you pay for...the reduced footprint and cooling costs are a bonus
It sounds like R.L Polk had the wrong architecture for the job. It doesn't sound like they dealt with lots of transactions. It sounds like they were doing some analytics on a large database (I could be wrong about this, but that's the impression I got from the article). If the latter is they case they need large quantities of bulk processing power. That's where clusters are much better. I'm surprised, however, that it takes fewer people to administer the Linux boxes than the mainframe. They must have laid off a bunch coders after squeezing the life out of them in a technology backwater. (Refering to the assembler code - not the fact it was a mainframe). I wouldn't be surprised if a good chunk of the performance improvement also came from the code re-write. After many years of patching and layering code you wind up with some pretty ugly stuff.
Leave the gun, take the cannoli -- Clemenza, The Godfather
because I don't have one (but I had to say it)
"Don't hate the media, become the media." -Jello Biafra
You better watch out. Around here, you can get perma-banned for not drinking the kool-aid and repeatedly claiming that Lunix is all things to all people, and that MS is an evil corporate overlord who has OS police in every household and office, forcing people at gunpoint to use Windoze.
Keep saying Lunix is already ready for the desktop... despite not being able to install properly on 80% of the time, and despite not having an installer package which works on all distros, and despite not being user-friendly. Because what grandma REALLY needs is to be able to choose from one of several million text editors, everything else be damned.
Go Lunix!
Go Security through Obscurity!
Thanks for the input--these software packages are excellent for professionals, but I don't know many people with that kind of money to drop on music as a hobby... $399 for kontakt 2, $599 for gigastudio 3.0, and $10,990 for symphonic cube! Of course to someone who is already set on Photoshop, Logic, and MS Office, money might be a moot point. For a techie on the cheap though, Linux can't be beat.
"Don't hate the media, become the media." -Jello Biafra
If you didn't know better, you'd swear it was an actual news article. It is actually a cleverly crafted press release.
For one thing, they are comparing an aging mainframe running aging software to a new grid running new software. The capabilities of the mainframe system are cast as representative of the mainframe against a backdrop of IBM declaring 2006 "The Year of the Mainframe".
For another thing, they can't get past their anti-mainframe (possibly anti-IBM) bias. Honestly, if they have the mainframe sitting in a back room somewhere doing little, they're wasting capacity. It might not be as fast, but it could contribute several Linux partitions to the grid.
a grid computing environment running Linux on more than 120 Dell servers
But did they got their 120 windows licenses money back?
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
On proper hardware, which is in fact usually a mainframe, Linux supports:
a. hot-add a CPU
b. hot-remove a CPU
c. hot-add RAM
d. hot-remove of most RAM
Linux will do that on any of:
a. bare zSeries mainframe hardware
b. a virtual machine (zSeries or PC)
c. to a limited extent on bare high-end server PC hardware and elsewhere
The latest and greatest mainframe is the System z9 EC, with a single main CPU rating (Model 2094-701) of ~600 zMIPS. It was introduced in 2005 (as the System z9-109) and renamed (with some non-processor enhancements) in 2006.
IBM mainframes hit 450 MIPS per CPU back in 2003, I believe (z990). Time marches on.
The replacement for the z800 rates about 480 zMIPS per CPU. It's the z9 BC. Between the z800 and the z9 BC was the z890, actually. I agree with the comments upthread that it's pretty silly to compare 2007 (or even 2006) hardware with circa 2002 hardware (and midrange hardware at that). And cost comparisons are wacky anyway: the company still has the old mainframe and is still paying to run it. What would the costs be to consolidate everything onto one shiny new mainframe? (Hint: new mainframes are substantially cheaper to operate than old mainframes, for a variety of reasons.) That question isn't apparently answered, perhaps because the answer would be embarrassing to the team that just spent a lot of money.
So where are the savings? How much lower are their z800 operating costs? (Hint: not much.) So they took some workload off the z800, moved it to somewhere else, spent quite a bit of money doing it, and...what happened to their total IT budget?
I agree, I'd be very interested to know what it would cost to do the whole project on a 2007 System z9, i.e. a new mainframe that's a lot cheaper to operate and which can run both Linux (much faster than a z800) and whatever is still running on the z800. And aside from all that, what's the service quality? It the Dell grid more or less reliable and available? How secure is it? What does the cost profile look like when it comes time to replace it? (Mainframes tend to have more residual value, while Dells get junked.) What are the software licensing impacts? (Mainframe Linux is extremely cheap in this regard.) Lots and lots of questions unanswered, and a lot of really bad economics. Why are some IT people so bad at economics anyway?
Most mainframe shops use a 4 year lifecycle in their budget analysis, but many do upgrades much more quickly than that. The big shops often upgrade as soon as something new is available: the economics are overwhelmingly in favor of doing so for such large installations.
These can be in place upgrades, by the way. You don't junk the whole system unlike, say, Dells.
Also, if you're looking at prices, please don't unless you understand what you're looking at. The price for a new mainframe is much different than the price for a capacity neutral upgrade (same number of MIPS) of an existing mainframe. MUCH different. In simple terms, when you buy a mainframe you pay a one-time processor capacity charge. So if you buy 350 MIPS you've got 350 MIPS. When it comes time to upgrade you pay a frame charge, but you don't pay again for the 350 MIPS. The same goes for Linux processors: buy a System z9 BC Linux processor at $95,000 and you own it forever and never pay it again. You only pay the frame charge when you're ready for an upgrade.
Every 2066 model (including the -002) has a minimum of 8 GB main memory. It is impossible to get one with less. Maximum is 32 GB. It was 2002's mid-range model for perspective. Quite a nice little system, but it's dated.
For reference, the likely replacement model would be a System z9 BC. However, if a lot of additional capacity (e.g. Linux) is desired, it would be economical to leap up to the System z9 EC because you can buy fractional z/OS capacities on that model now (i.e. something that would be a good match for the 350 MIPS they have rather than jumping up to ~600 MIPS for a full CPU). The BC also has a minimum 8 GB memory but can expand up to 64 GB. The EC is 16 GB minimum and 512 GB maximum (per frame).
That's correct, and you make a very good point. Moreover, the execution integrity applies to any operating system running on the IBM machine, including Linux. That's a very important distinction, by the way. This functionality is pushed way down into the hardware layers. Linux just goes along for the ride -- a very cushy, comfortable, secure ride.
Files can be distributed amongst the nodes for speed and redundancy.
This is a mindset of grid computing, perhaps for this ubiquitous analysis of static geologic files for oil and such I am always reading about in the buzzword press, but it is not reality in the real world of business computing.
Files are accessed and updated concurrently by hundreds of users and jobs. There can be no "distribution" of a file somewhere to do whatever it is you have in mind in a serious enterprise environment.
Not that people don't architect FTP'ing this stuff right and left to get snapshots to PC servers anyway.
rd
Y'know, to keep the old man company. Otherwise, it might develop an AI that will send a beacon signal out to the U.S.S. Enterprise, and we all know what happens then...
Even if you're lucky enough to use 1 Gbit/s cards and cabling and routers that can handle it, the aggregate throughput between nodes is 128 MB/s.
That might be true if you were using an Ethernet hub, but nobody does that for Gigabit Ethernet. Gigabit switches typically have a switching fabric capable of bandwidth well in excess of 1Gbit/sec. Of course, the connection between two nodes is limited to 1Gbit/sec, but the aggregate bandwidth is higher.
Just as a simple datapoint, I run a real application on a cluster of PCs over gigabit ethernet, using a relatively cheap gigabit switch. Aggregate bandwidth is over 300mb/sec. I doubt the switch could handle anywhere near the 4GB/sec you quote, but I imagine this hardware was quite a bit cheaper.
This may be a dumb question, but why is that a matter of physics? Aside from cost, what's preventing them from making long rigid conduits with more data lines? I suppose there's voltage drop and electrical interference, but what about optical? (Posting AC in case it (really is a|is a really) dumb question, but I will come back and read the answer.)
The pronunciation changes as you add letters to it: tough, though, trough, through, thought.
(Also, change the first letter, and the vowel sound changes: bough, dough, rough.)
Of course, "one" does it, too: one, gone, hone, none.
Then there's "woman"/"women", whose first syllable's pronunciation changes based on the second syllable's spelling.Also: its vs it's, affect vs effect, than vs then, there vs their vs they're, and misspellings like ect for etc. and wan't for want.
"the Linux grid outperforming the mainframe by 70% with a 65% reduction in hardware costs"
I've seen tons of articles saying the same thing for the last five years - running a mainframe is BRAINDEAD if you don't have at least 15 or 20 different applications running on it that can take advantage of the multiple virtual machines.
Years ago I read where a major oil company dumped a mainframe for a cluster of Intel boxes and got four or five times better performance on their apps while the cost of the whole thing equaled the MAINTENANCE charges alone for the mainframe.
In other words, you can run your apps on Intel servers with several times more performance for about 10-20% of the cost of a mainframe.
That is what I call a no-brainer in architecture decision making.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Your IFL gets faster when you do a frame upgrade. For example, if you bought an IFL in early 2001 it'd be about 200 MIPS. When you did your late 2005 frame upgrade to a System z9 EC it's more like 600 (three times faster), and you didn't pay a dime for the speed bump (except the frame charge). When the next frame comes, the same thing happens. Over and over.
Of course that's not including the other stuff you get. Actually you could have purchased a 31-bit IFL, and the upgrade to 64-bit would have been free with your frame charge. Likewise, any instruction set improvements are free, and that's already happened even within the 64-bit processors (e.g. for crypto -- the EC has AES embedded in the processor hardware, and yes Linux uses it).
Make sense now?