IBM Mainframe Running World's Fastest Commercial Processor 158
dcblogs writes "IBM's new mainframe includes a 5.5-GHz processor, which may be the world's fastest commercial processor, say analysts. This new system, the zEnterprise EC12, can also support more than 6-TB of flash memory to help speed data processing. The latest chip has six cores, up from four in the prior generation two years ago. But Jeff Frey, the CTO of the System Z platform, says they aren't trading off single-thread performance in the mainframe with the additional cores. There are still many customers who have applications that execute processes serially, such as batch applications, he said. This latest chip was produced at 32 nanometers, versus 45 nanometers in the earlier system. This smaller size allows more cache on the chip, in this case 33% more Level-2 cache. The system has doubled the L3 and L4 cache over the prior generation."
Reading the words "new mainframe" (Score:2)
Re:Reading the words "new mainframe" (Score:4, Informative)
Mainframes run a surprising amount of critical workloads in the real world. They're vastly different than open systems, but they can be kept running through almost anything, if you're willing to spend enough money.
Re:Reading the words "new mainframe" (Score:4, Insightful)
Re:Reading the words "new mainframe" (Score:4, Informative)
It may not be just you. But I think a lot of people really have no idea of just how many mainframes are still chugging away doing what they've always done.
My wife does outsourced SAN storage, and they still have a couple of clients with big iron running.
Every couple of years when everybody has forgotten about the machines, an IBM tech will call up and say that the machine has phoned home and has a part that needs to be swapped out and that he needs to go onsite. Which usually leads to several hours of people trying to remember what it is and where it is (except the guys who work in the data center, who can't miss it).
I've worked in several places that have had mainframes for literally decades. And I've even worked on a project or two which tried to replace ancient, purpose built software with some shiny new stuff. In the cases I've seen, after spending a few years a a few million dollars ... they still can't replace the mainframe and scrap the project.
I knew someone in the early 2000's who had retired from his job with a full pension, and was back as a consultant making at least 3x his old salary because they no longer could find someone who knew the machines and the software like he did.
Mainframes haven't gone away. Not by any stretch. And I bet this one still runs the stuff from the IBM 360 days quite nicely.
Re: (Score:2)
Mainframes do a bunch of tasks extremely well. The problem is that there is a "cheapest at any cost" mentality in IT, which is why this type of technology seems to be outmoded.
If businesses looked at the TCO of a mainframe, oftentimes, they would be better off, especially because of the CPU power per square foot of server room space, which a mainframe excels at. This is also true to a lesser extent with the higher end Oracle SPARC and IBM POWER7 machines.
The one advantage of mainframes is that once set up
L4 cache (Score:3)
How does the L4 cache in these processors work? Generally going to anything off die is going to induce a major latency penalty due to the need to go through a driver stage which can handle outside interference. How can they make the L4 cache fast enough that its small size doesn't make it basically pointless versus just going to main memory?
Re: (Score:2)
Small is a relative term. The L4 cache is almost 200 Mb on these. Of course, it all depends on the how the math works out. As long as it's faster than going to RAM there will be plenty of situations where it pays off.
Re:L4 cache (Score:5, Informative)
Re: (Score:2)
The outboard cache is off the die, but within the same ceramic module. That means no sockets in the way and very short connecting wires. The cvache chips themselves can also be faster than the chips you'd find on a DIMM.
Ming Mecca (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Or they will be like me, be interested, look it up, and then laugh.
I've since added the movie to the queue.
Then again I'm not part of the mainframe crowd. Damn cool kids with their expensive toys.
Memory performance? (Score:2)
So it was my understanding that part of the reason consumer CPUs didn't tend to go above 3-4GHz was that, at those speeds, the electrons can't actually move through the wires fast enough. Specifically for doing memory reads -- at 5.5GHz, I'm calculating about 4cm per clock cycle -- which may be further than the memory is physically located on a normal desktop PC. Meaning it would take not just two, but possibly three or four clock cycles to read a value from main memory.
Granted, on a server, main memory may
Re:Memory performance? (Score:5, Informative)
CPUs have not accessed main memory synchronously in decades. There are many hundreds of cycles lost if the processor stalls on a RAM access, not just from the length of the wiring but the addressing logic too. In fact, modern CPUs don't do word-level access to RAM, but rather pull in whole cache lines in a more packetized memory access protocol. Even in a multi-CPU SMP system, they don't actually communicate through system RAM anymore, but rather communicate CPU-to-CPU with a cache coherency protocol that provides the illusion of a shared system RAM. Each CPU really has its own set of local RAM behind its own cache and on-chip memory controller.
Even the L2 or L3 caches are unable to keep up with the CPU, but they are still significantly faster than system RAM, so they still help when the working set can fit there.
Re:Memory performance? (Score:4, Informative)
These chips make up for the high latencies by having many instructions being executed simultaneously, so if one dependency chain completely stalls out on a cache miss any other dependency chains can still fill up the execution units keeping the processor just as busy as if there were no stall at all until everything left in the pipeline is dependent on the result of the stalled out operation.
Re: (Score:2)
Re: (Score:2)
Wow, I thought L1 cache was much faster. Thank God there are 16 registers.
But it looks that passing arguments in the stack is moderately expensive for a small function. Am I right?
it is..relatively speaking (Score:2)
I would argue that the jump from machine code to assembly to C is much smaller than the jump from C to lisp/bash/perl/prolog
Except.... (Score:2, Informative)
Except the 5.5GHz may not be all that fast, as the Z-line of CPUs are the old IBM 360 instruction set, which is is so large, complex, and baroque that it is mostly usually implemented through a thick layer of microcode.
So 5.5GHz may be the speed of the microcode level, the actual "machine instructions" may be a considerable sub-multiple of that.
Re:Except.... (Score:4, Interesting)
Re:Except.... (Score:5, Informative)
No, that's not a correct supposition -- quite the opposite, actually. All processors, including Intel X86, use microcode (or what IBM calls millicode) to a degree.
At least from what I've read about the past few generations of S/3x0 chips, millicode is more like PALcode on the Alpha processor than like traditional microcode, i.e. it's a combination of regular machine code and processor-specific instructions that access specialized registers etc., running in a special processor mode with (presumably) fast entry and exit, support for said processor-specific instructions (which presumably trap in either both "problem state", i.e. user mode, and "supervisor state", i.e. kernel mode), and its own bank of general-purpose registers (part of the "fast entry and exit"). Instructions implemented in millicode trap to millicode routines that implement them.
What IBM called "microcode" rather than "millicode" was implemented using processor-specific instructions completely different from the machine's instruction set (instructions often having fields that directly controlled gates).
(And then there's System/38 and the pre-PowerPC AS/400, where the processor instruction set was a CISC instruction set implemented using microcode, and where the compilers available to customers generated code in an extremely CISCy instruction set [ibm.com] that the low levels of the OS translated into machine code and ran. For legal reasons - they didn't want to have to be required to make the low-level OS code available to "plug-compatible manufacturers", i.e. cloners - they not only called the microcode that implemented the processor instruction set "microcode" ("horizontal microcode", as it probably was "fields directly control gates"-style horizontal microcode), they also called the aforementioned low level OS code "microcode" as well, even though it ran from main memory and its instruction set was the instruction set that was actually executed in application code ("vertical microcode"), and had the group working on that code report to a manager in the hardware group. See Frank Soltis's Inside the AS/400.)
IBM knows it well. After all, they invented microcode/millicode in the System/360 in 1965.
"Invented", no; the paper generally considered to have introduced the concept was "Microprogramming and the Design of the Control Circuits in an Electronic Digital Computer" [microsoft.com], by Maurice Wilkes and J. B. Stringer, from 1953. S/360 may have been the first line of computers to use microcode in most of the processors (S/360 Model 75 was, I think, implemented completely in hardwired logic).
Very cutting edge -- so cutting edge I've got to crack open some engineering manuals to try to figure out what they've done, although they probably need to write those manuals.
Well, for the previous generation, there's Volume 56, Issue 1.2 of the IBM Journal of Research and Development [ieee.org] has some papers on the z196, but, alas, not for free online. They may publish an issue on the zEC12 at some point.
Re: (Score:2)
and 64 bit doesn't automatically take 2x the footprint
Are you referring to instruction density, or to data structure density with 64-bit pointers?
unlike Intel, who still can't get it right.
Actually, that's actually AMD's fault, if you're complaining about the x86-64 architecture (unless you blame Intel for not having done a better job than AMD).
Intel's stuff is also microcoded and implemented as RISC under the covers.
Yup, the whole "translate the "complicated" instructions to microops and schedule and run the microops independently" stuff is also being done in the z196 and, presumably, its zEC12 successors. As IBM zEnterprise 196 microprocessor and cache subsystem [ieee.org] (not avai
don't blame intel for size of 64-bit binaries (Score:2)
The x86_64 cpus support a mode called x32 where they use the 64-bit CPU mode but with 32-bit pointers. The hardware supports it, but there is relatively little software support. A Linux port is currently in progress.
Damn marketdroids (Score:2)
Re: (Score:2)
Too bad TurboHercules collapsed (Score:2)
We could have gotten some meaningful benchmarks. According tho this Register arcticle [theregister.co.uk]
Re: (Score:2)
Arrgh
That last sentence should be "On the other hand, if your old and creaky code can't be divvied up among a multiplicity of cores, the existence of a far cheaper 64 core, 8 way Nehelem EX machine (or its current equivalent) that's only twice as fast as a single zEC12 core shouldn't much matter."
Re: (Score:2)
Re: (Score:2)
Those are emulated cores under hercules. If you were running oracle you would run them natively on the cores, and in that case its closer to 1:1 with the mainframe.
Re: (Score:2)
Huh? I think his Orale example misses the point, but your statement is a bit off. In any case. I doubt you see a lot of people going the Orale on Z route.
Re: (Score:2)
The numbers provided by TurboHercules are most certainly complete bullshit. Actual MIPS are determined by running standard benchmarks against simulated workload. A 1200 MIPS machine is going to be driving a whole lot of I/O in those benchmarks, and there is no way that Hercules emulated processor and emulated I/O is going to be able to pull that off.
If they didn't test with IBMs standard LSPR tests, their numbers are useless.
Benchmarks? (Score:3)
I'll believe their claims when I see some test results they can back it up with.
Re: (Score:2)
Re: (Score:2)
And non-I/O workloads are ever so common in enterprise computing.
cat TFA | sed -e 's/Flash Express/Cache Express/g' (Score:2)
With flash memory you read a block, flip some bits, and write it back to modify that block. Not only that, but Flash memory will wear out after so many reads and writes. That would be devistating to a CPU.
Re: (Score:2)
Re:CPU (Score:5, Informative)
Re: (Score:2)
https://en.wikipedia.org/wiki/IBM_z196_(microprocessor) [wikipedia.org]
Actually, the z196 is the microprocessor in the previous generation. An IBM paper on the zEC12 [ibm.com] refers to the new microprocessor as the "zEC12 processor chip" or just "the zEC12 chip". As they're not selling it on the open market, there's not much reason to give the processor chip its own name, independent from the name of the systems in which it's being used.
Re: (Score:3)
Hmmm, six cores with each running at 1 ghz equals 6 ghz with a 5% overhead makes it 5.7 ghz maximum... IBM Marketing!!!!
And the published information supporting your assumption that the cores are only running at 1GHz, and the 5.7 GHz comes from multiplying the clock rate by the number of cores and subtracting 5% as overhead, rather than each core truly running at 5.7 GHz, is?
Re: (Score:2)
Why does the article not mention the name of the CPU?
You're probably not buying one at tigerdirect anytime soon, so it doesn't really matter.
It does run linux, which is kinda cool.
http://www.debian.org/ports/s390/ [debian.org]
Re: (Score:2)
Why does the article not mention the name of the CPU? Is only its clock speed faster, or also its execution? Can we also use this CPU in consumer computers or is this for IBM Mainframes?
No. They obviously want to profit from high speed trading.
Re: (Score:3, Informative)
Re: (Score:2)
Multinational corporations don't shell out $20M for a mainframe upgrade without knowing exactly what they're getting.
uh, they tend to exactly shell out the money without knowing exactly what they're getting since they're contracting the decision out anyhow.
sure, it would be nice if the whole db fitted on the cache on the cpu.. but uh, you're not getting 48gb of on-die cache of course. you're not going to get that for 20 mil.
MOD PARENT OVERRATED (it is factually incorrect) (Score:2)
Wrong. See http://hardware.slashdot.org/comments.pl?sid=3078075&cid=41151983 [slashdot.org]
MODS: mod it down until it is at score 1 (no need to go to -1 and burn the guy's Karma).
And to jthill: nothing personal.
Re: (Score:2)
You don't even try to make sense.
Please go troll somewhere else.
And by the way, my Karma is good.
Re:CPU (Score:5, Interesting)
Re: (Score:2)
Re:CPU (Score:5, Informative)
L3 is 48MB, (see p. 43) [ibm.com], not GB as The Register had it, thanks for noticing that.
Re: (Score:2)
Re:Article says 'may be', i.e. no (Score:4, Insightful)
So, you're comparing a ridiculous configuration of a nitrogen-cooled, over-clocked processor that will maybe run long enough to get a screen shot of it running, to a commercial processor that is designed to run at that speed non-stop for years and years? Yeah, that makes sense.
Re:No the basic Core i& extreme will smoke it (Score:5, Informative)
Re: (Score:3)
Re:Thanks, I've already found some Benchmarks (Score:5, Informative)
OK, let's put some of this stupidity to rest.
First, nobody who knows anything uses MIPS to compare perfomance between two different architectures. MIPS is only marginally useful in the best of conditions, and even then is only useful as a relative measure between two machines of the same architecture running the same workload.
Second, Core i7 servers execute 178 BILLION instructions every second, on average? Seriously? 80 instructions per clock cycle, sustained? Bullshit.
Third, your nice shiny rack of Core i7 servers doesn't mean anything if it can't run your software.
Fourth, the actual performance of a Z114 processor is around 780 MIPS, not 26. So why do they have that 26 MIPS 'dialed down' model? Because some customer asked for it. Why would a customer pay $800K for a 780 MIPS machine when he only has 26 MIPS of workload? Why would the customer pay software licensing fees for a 780 MIPS machine when he only has 26 MIPS of workload?
Fifth, 'your experience' with IBM mainframes is non-existant, or you wouldn't be making these stupid mistakes and claims.
Re: (Score:2)
MIPS is only marginally useful in the best of conditions, and even then is only useful as a relative measure between two machines of the same architecture running the same workload.
I rather suspect that "MIPS", these days, doesn't measure the how many millions of instructions a processor executes per second. I don't know what the "MIPS" figures for IBM mainframes count, but the figure everybody's quoting for the Core i7 processor is "Dhrystone [wikipedia.org] MIPS", which, as the Wikipedia article says, is "obtained when the Dhrystone score is divided by 1757 (the number of Dhrystones per second obtained on the VAX 11/780, nominally a 1 MIPS machine". Unless the "MIPS" figure for IBM mainframes rep
Re: (Score:2)
Seriously? 80 instructions per clock cycle, sustained? Bullshit.
Thats caused by people multiplying the single core numbers by the core/thread count. You can easily buy an 80 core x86's (HP DL980G7). Which leaves the IPC at only 1 (using your number of 80 IPC), which is probably actually really low for that machine considering the cores are super-scalar, and its hyperthreaded.
That is in fact what IBM does with their zseries too, the single core numbers are only like 1.3k MIPS, times 64 or whatnot for the big
Re: (Score:2)
Your 177730 MIPS figure is mirrored by this wikipedia page [wikipedia.org]. Using the same criteria, 30 MIPS is around a 33 MHz 80486,or perhaps even a 68040.
Unless you have an irrational suspicion of IBM, it's fairly reasonable to assume that a mainframe MIP is not a Dhrystone MIP.
Re: (Score:3, Informative)
CPU isn't the single item with mainframes. Mainframes tend to have large I/O buses, and that is something that tends to be forgotten about when people talk about CPU power.
Mainframes are designed to do business tasks, be it CICS operations, DB2 transactions, or other integer based operations that require tons of data going in and tons of data going out at a time. This is why IBM has such a good caching design. Having the ability to get the numbers into and out of the CPUs is what mainframes are designed
Re: (Score:2)
Re: (Score:2)
This ius what I've seen woring in a mainframe shop as well. The performance is not great, and the OS and tools were horrid (this is z/OS, not Linux). The costs were astonomical for the performance as well. The only thing they can really clain is very good reliability, but in the end, it's human error that gets you every time. We had well administered Windows servers running database, etc, that were kicking the mainframe's ass in both performance and in uptime (systems, not hardware). If you never change *an
Re: (Score:3)
What exactly are you basing your claims on? Just pulling things out of thin air?
Here are some things that IBMs customers care about, where are the Core i7 Extreme numbers for these?
How many CICS transactions can I process per second? How many IMS updates? How about DB2 transactions? How many SSL transactions? What differences are there in performance for on-line vs batch processing? Can I tune the system to maximize performance for my particular workload?
Re: (Score:2)
Here are some things that IBMs customers care about, where are the Core i7 Extreme numbers for these?
How many CICS transactions can I process per second? How many IMS updates?
Well, you're unlikely to get numbers for the first of those, given that IBM apparently killed off CICS for Windows [ibm.com] and I'm not sure which x86 UN*Xes, if any, got versions of CICS. I'm not sure to what extent TXSeries for Multiplatforms [ibm.com] would let you, for example, run CICS on Windows Server or Linux.
As for the second, as far as I know, IBM's never ported IMS to any non-mainframe OS.
How about DB2 transactions?
About 13,000 XML transactions per second [sourceforge.net] in at least one benchmark - but those were Xeons, not Cores (server rather than deskt
Re: (Score:2)
Well, yes, that was my point. The workloads run on mainframes are different than the workloads run on other processors. Therefore, there are no benchmarks which can be accurately used to compare them.
These people that keep harping on the 'IBM won't do benchmarks' theme are completely missing the point. It is like saying that because GE Locomotives does not publish 'MPG' or '0 to 60' figures that means that they are hiding something and that obviously a Toyota is a better vehicle. Well, where are the 'f
Re: (Score:2)
Well, yes, that was my point. The workloads run on mainframes are different than the workloads run on other processors.
Some workloads run on mainframes are different from the workloads run on other systems. A workload using software that only runs on, say, z/OS would be such a workload, as per my comment on IMS.
Other workloads are run on many different types of large systems, whether the processors happen to execute a descendant of the System/360 instruction set and the I/O subsystem happens to run S/3x0-style channel programs or not. DB2 workloads could be such a workload, as per my comment on DB2.
Re:bogus claims (Score:4, Informative)
They claimed "faster", not "more powerful"; clock frequency is the only thing they need to reference for that claim.
Re:bogus claims (Score:5, Informative)
Re:bogus claims (Score:4, Interesting)
There are some engineering tricks I've seen IBM use which are pretty cool. Take the POWER7 CPU line for example. You can disable every other core, allowing the cores that are operational use the cache of the cores that are not on. This gives not just cache, but allows a higher clock speed. Of course, this feature is mainly used to deal with applications which are licensed by the hardware cores present.
Mainframes are probably one of the most underutilized tools out there. However, for performance per square foot in the data center, they are hard to beat these days.
Of course, the biggest advantage: It isn't x86. With virtually everything running on the x86 or amd64 platform, all it would take is an undocumented instruction similar to the F0 0F bug that happens to give ring 0 access, and virtually the whole world is vulnerable with absolutely zero way of protecting against it except reaching for the network cable or power switch.
Re: (Score:2)
Mainframes are probably one of the most underutilized tools out there. However, for performance per square foot in the data center, they are hard to beat these days.
I really don't believe you are right about that. The core density of mainframes is rather sad compared to Google-style densely packed rack mounts. You can only fit about 100 user accessible processors in one mainframe, which gives you around 600 cores. You can easily fit 800 x86 cores in a standard 42U rack, even with bog-standard 1U servers while leaving room for switches and cooling, and you can more than double that if footprint is your main concern. In contrast, that mainframe won't fit in a standard 19
Re: (Score:3)
mainframes generally run in high availability and high uptime enviroments.
you want five nines, you want a mainframe.
a cluster of x86s might reach the same performance specs for a fraction of the price, but it won't give you the same reliability.
Re: (Score:2)
It is fairly trivial for white-box clusters to reach five nines. When was Google's last downtime?
Re: (Score:2)
x86 is not a monoculture. That is an absurd claim.
All problems with the x86 instruction set have lay in its implementation, which differs wildly from processor set to processor set. The implementations of the ISA may have security issues, but there is no inherent insecurity in the x86 instruction set.
Re:bogus claims (Score:5, Informative)
IBM gets the speed because cost is no option. Here is how they do it.
1. Low yield. These chips have a very large die size so the yield is going to be lower but the price is high so the trade off works.
2. Binning. The slower chips will go into the lower end machines that use the Z114.
3. Multi chip modules again to allow careful selection and improved yields.
4. Crazy levels of cooling. These have the very best cooling they can fit.
5. Professional operators, maintenance, and construction. The entire machine will be built like an expensive watch from the cooling to the memory system. The operators will follow all the procedures and if something is not perfect they will call IBM to send out a tech if the computer didn't do it.
Other companies know how IBM does this they just do not have the resources in place to compete with IBM in this market. Instead they go for the easier lower hanging fruit.
Too bad IBM blew it with the PC. If they had not been under extreme anti-trust pressure and had faith that PC where going to take off they could have used a 16 bit version of the System 360 ISA for the CPU maybe based on the 360/20 or maybe the 22.
Re: (Score:2)
Re: (Score:2)
But such businesses likely exist -- those business whose real business problem is selling processors and whose processors run UnixBench very well.
Re: (Score:2)
It's a matter of intended load. Yes, the mainframe looks bad when it is running a benchmark intended for a GP CPU. However, let the Xeon run a massive out of cache application and watch it spend most of it's time waiting on memory.
Kinda like your typical passenger car easily leaves a dump truck in the dust when the light turns green until you try it with 20 tons of rocks in your trunk.
Re: (Score:2)
Generally, the larger the memory system the longer the memory latency. Hence the need for larger caches. The one thing the z does bring to the table is extremely large caches. Which helps a lot if you are sitting in that range between fitting in cache or not. The problem is (at least with the previous generation CPU) is that the memory latency is not as good as you assume. You can't throw money at the latency problem, like you can with the bandwidth or capacity ones.
From what I can tell from my z114 the mem
Re: (Score:2)
When you can find a Xeon with OVER 1 GIG of cache, my example will suck. That's a BIG window for apps that go out of cache on a Xeon but not on a z CPU.
There's still plenty of reason to go with the Xeon, of course. If you have apps that stay reasonably in cache for a Xeon (and there are plenty) or you don't happen to have a few million burning a hole in your pocket (sadly, very common), the Xeon is a good choice.
Re: (Score:2)
Re: (Score:3)
with minimal performance gain, and increase in power.
Re: (Score:3)
Laptop chips? Please. We're moving away from that. The tradition these days is to compare everything to your cell phone-- Your cell phone beats the pants of a Cray, and so on.
Re:Overpriced crap (Score:5, Insightful)
You have a point, but you missed it. At least talk in terms of modern workloads. These machines are running over 1,500 MIPS. Your talk of systems running 25-30 MIPS is silly. If your 114 is running at 25 MIPS it is broken. Really, really broken.
No single processor desktop CPU can handle that. Even dual processors. Hercules is no where near the performance of a modern Z series mainframe.
Can you build a server complex with more MIPS for less money? Absolutely. The question becomes what is the cost and risk of migrating that legacy application.
Re: (Score:2)
Entry level z114 is indeed 26 mips for $75000.
http://www.tech-news.com/publib/pl2818.html
Which is a joke surely? $400,000 will get you 330 mips, which is erm, surely a mistake???!! It's way way too low:
http://en.wikipedia.org/wiki/Instructions_per_second
Core i7 is 177,730 MIPS at 3.3 Ghz.
I suspect that the "MIPS" figures for IBM mainframes do not, in fact, represent a count of the number of instructions executed per second, in units of one million instructions. I don't know how the "MIPS" figures are generated, but I suspect they're intended solely to be treated as a relative CPU performance figure for comparing two machines. As such, they probably can't be validly compared to other "MIPS" figures measured in some way different from the way IBM mainframe "MIPS" figures are measured.
The 1
Re: (Score:2)
There is no guarantee that Dhrystone "MIPS" numbers correspond at all to IBM "MIPS" numbers.
Correct, a MI (million instructions) on the z, isn't equal to a MI on any other platform. That said IBM rates their machines in "MIPS", for comparison purposes. A P90 is rated at roughly 70 Dhrystone MIPS per (http://www.alternatewars.com/BBOW/Computing/Computing_Power.htm). When I stated they there are roughly the same performance I meant it. So, you can use that as a conversion factor. Given the inaccuracies of the
Re: (Score:2)
Correct, a MI (million instructions) on the z, isn't equal to a MI on any other platform.
A million instructions on instruction set architecture A isn't equal to a million instructions on instruction set architecture B, for all values of A and B (modulo "A" being "32-bit X" and "B" being "64-bit X", perhaps, or other cases where A and B are variants of the same ISA). There's nothing unique here about S/360 and its descendants.
That said IBM rates their machines in "MIPS", for comparison purposes.
Unless they actually count instructions, they should perhaps call them "zUPS" or something such as that, along the lines of DEC publishing VUPs (VAX Units of Performance)
Re: (Score:2)
So what benchmark did you run to determine that a Pentium P90 had the same performance as a base z114?
A bunch of in house stuff, as well as some standalone open source benchmarks I could get my hands on, and would compile under OMVS. I use the P90 example because that is what nbench scored the single core performance as (single threaded, fairly small working set), and the variation in its results were fairly consistent with a number of other benchmarks I was running. Obviously changing the weighting could s
Re: (Score:2)
Where does IBM rate their machine in MIPS?
Re: (Score:2)
Where does IBM rate their machine in MIPS?
In the IBM zEnterprise z196 server overview [ibm.com]:
and in the IBM zEnterprise EC12 Technical Guide [ibm.com]:
Re: (Score:2)
Re:Overpriced crap (Score:4, Interesting)
I'm quite sure that for the applications people actually use mainframes for, you're utterly wrong.
Not only do they scale massively higher in terms of throughput, they also manage to do it with obscene uptimes (measured in years) and reliability nothing can compare to.
For certain kinds of applications, what you say is largely true. But at the huge end for things like banking, financial transactions, and airline reservations ... there's really no comparison.
I've worked on projects trying to do exactly this. And I've seen a couple of them fail.
Trying to map out all of the use cases for software which is mission critical and has been around since the 60's can actually prove to be exceedingly challenging if not impossible.
I'm just not convinced that for the kinds of applications and environments where people will run mainframes that what you suggest would give the same performance or scalability as a big giant mainframe. There just seems to be something missing from that picture, and to me it's the sheer volume of stuff these things handle. Certainly not even in the same category as what you call a midrange desktop.
Re: (Score:2)
I'm quite sure that for the applications people actually use mainframes for, you're utterly wrong. Not only do they scale massively higher in terms of throughput, they also manage to do it with obscene uptimes (measured in years) and reliability nothing can compare to.
No, this is where you are wrong, open system are far more advanced in both processing and IO capabilities. In fact with the latest x86's the RAS features are equivalent or better. If you had actually maintained a mainframe for any length of ti
Re: (Score:2)
Modern SSD, FC, ethernet and inifiniband connections on x86 are light years beyond the mainframe.
Are they behind the Fibre Channel, Ethernet, and Infiniband connectors in the zEC12 mainframe [ibm.com]? (Presumably by "SSD" you mean something other than "solid state drive", given that a "solid state drive" is a type of secondary storage, not a connector.)
Re: (Score:2)
Yes, they tend to lag about a generation.
You can buy 16Gbit FC from IBM for x series. The z only has 8G. Ethernet is 10G on OSA, 40G Ethernet is available.
Basically, the open systems peripheral market is where all the cutting edge stuff is. No one who has a great idea for how to make a faster/better IO adapter limits themselves to selling 100 of them into the mainframe space. Especially when they can get purchased for billions of dollars by the likes of Dell, EMC and HP.
When it comes to SSD's I was talking
Re: (Score:2)
When it comes to SSD's I was talking solid state, which can be attached via FC on the z, but the performance is nowhere near what can be achieved with something like the fusionIO PCIe based adapters.
So how about attaching them to the z with a fusionIO PCIe-based adapter? "Overview of IBM zEnterprise 196 I/O subsystem with focus on new PCI Express infrastructure [ieee.org]" says that PCIe adapters can be directly attached. Perhaps there are no z/OS drivers for them, but Linux drivers might exist. You can't directly memory-map PCI devices - special instructions are required - but, at least as I remember from my NetApp days, on Alpha you couldn't necessarily make the same sort of direct references to PCI space th
Re: (Score:2)
Perhaps there are no z/OS drivers for them, but Linux drivers might exist.
The only PCIe adapters you can plug in are ones sold by IBM for the z. Getting them working under zos is pretty much a non starter, zos is _STUPID_ it can't even talk to normal FC attached disks even though the adapter can do it under linux.
If you want to have a lot of fun hacking a z PCIe layer into linux you might get it working. That is after you hack up zvm to allow passthough, or the LPAR code... Linux is only sort of running o
Re: (Score:2)
Well, I'd certainly believe that vmware has gotten a lot right. I haven't worked in a place that doesn't have a large vmware infrastructure in quite some time.
Re: (Score:3)
I've seen a couple of 'get off the Mainframe' projects "succeed".
They got systems off the mainframe, but it took years, was a very expensive process & the resulting heap of servers didn't save any money. Reliability goes downhill, manageability goes downhill, bang-for-buck goes downhill. Oh, and they still have a mainframe! (some things get moved 'out of scope')
I still get paid though :-)
Re: (Score:2)
You shouldn't be using a mainframe if you are making these types of arguments. Mainframes were never meant to be the fastest at single tasks where a mips rating might be relevant. They are meant for processing enormous amounts of data/transactions with high throughput and reliability (including fault tolerance). People aren't spending this kind of dough on something they don't need or think they could get for cheaper/better elsewhere. Wasn't the mainframe declared dead in the 80s? 90s? 2000? Where are the c
Re: (Score:2)
here are the competitive systems you seem to think are possible? Quit your job and go make some. Just don't collect unemployment when you fail.
BTW: My day job in the early 90's was working for a very successful company selling a niche application to county/city governments. In nearly every case, we were replacing mainframes. Good luck finding a mainframe in that particular space. We had a couple competitors doing exactly the same thing. By the late 1990's finding a mainframe in that space was hard. They are
Re: (Score:3)
You have no idea what you're talking about.
How many (hundreds) of simultaneous users will your cheap configuration support? What (fraction of a percent) is your unplanned downtime under load?
Comparing mainframe MIPs to PC MIPs makes no sense - PCs have nowhere near the throughput or reliability. I used to work on a mainframe when PCs first came out. Even then, it was clear that the two or three or four MIPs on the PC were in no way superior to the 1 MIP on a 4341 mainframe - the mainframe supported about
Re: (Score:3)
They fail against mid-range x86 Xeon rackmount server in every non-I/O benchmark.
But what if you need I/O?
Re: (Score:2)
But what if you need I/O?
Then you buy a high end Fiber channel or infiniband disk array for your x86. Or for that matter you go cheap and buy a fusionIO, and beat an 8 figure mainframe. IO on a modern x86 is usually limited by the peripheral, not by the bus or memory bandwidth. Its fairly easy to drive 10's of GB (bytes!)/sec of IO bandwidth on an x86. The problem is finding a network link to support it, or a disk farm to source it from.