A lot has changed between yesterday, when the System z9 was launched in New York, and when the System/360 made its debut in April 1964. But a lot remains the same, too.
With the advent of the z9 CISC mainframe processors and the Danu System z9 mainframe servers that employ these new processors, IBM is stopping the use of the brand name eServer zSeries. IBM’s marketeers are trying to make a clean break with the last five years of mainframe marketing, to make it clear in its messaging that these machines are in some way different than prior machines.
It is unclear why vendors feel compelled to make such marketing changes, but clearly they do and they do not do it lightly. The printing and Web expenses to make such changes are huge for a company like IBM, but the cost and effort of educating the sales force and reseller channel is even higher.
Presumably, IBM has good reasons to kill off the zSeries brand and get everyone back to thinking in terms of system brands again. When IBM did a massive rebranding in October 2000 to create the eServer, it did so to try to simplify its marketing message even though the zSeries was pretty distinct from the Power-based iSeries and pSeries machines and the X86-based xSeries machines. IBM wanted to stress the things these platforms had in common – logical partitioning, support for Linux, support for Java, and all of the reliability and security features that you expect from IBM machines.
No one outside of IBM really says eServer, except where they have to, and in this regard the eServer unifying brand has been largely a failure. People still buy server platforms based on the core attributes of the server–its processors, its system architecture, and its operating systems–and rebranding cannot change that.
So why the System z9 brand for the new mainframe? Maybe IBM was running out of three-digit model numbers after the zSeries 990. Maybe IBM wanted to harken back to its past brands: the System/360, System/370, ES/3090, and ES/9000 bipolar mainframes and the six generations of the System/390 9672 CMOS mainframes.
Whatever the reason, IBM is not saying. But presumably this has something to do with selling the new machines, because marketing departments are supposed to take the technology that the hardware and software engineers create and that the factories build and create a story about why you need one. This has to be a compelling story that a sales force and a reseller channel (not so much an issue at the high-end of the mainframe market, where hardware resellers are all but shut out) can chant compellingly and convincingly over and over again as they make their pitches and try to make some money.
While IBM’s marketing and sales messages will be about how the System z9 is a radical break with earlier technology, the fact remains that the Danu mainframe servers represent an evolutionary change that is solidly based on the technology used in the earlier zSeries 900 and 990 servers. Mark Anzani, the vice president of development for the System z9 product line, walked me through the box in a recent interview and helped me understand how it is similar to and different from the prior zSeries machines.
The Freeway zSeries 900 servers that were announced in the fall of 2000 concurrent with the eServer rebranding were comprised of thermal conduction modules (TCMs) that packed 20 processors and other electronics into a single, three-dimensional block; up to 16 processors in total were available to a single z/OS operating system image, with the remaining for being used as spares.
The CISC processors at the heart of the Freeways, presumably called the z7 chips by IBM because the latest ones are called z9s, ran at up to 770 MHz, delivered about 300 MIPS of mainframe processing capacity, and were only available in single-core implementations. The largest machine was rated at 3,192 aggregate MIPS of processing capacity. Including special Linux-only variants, the Freeway zSeries 900 mainframes came in 42 different basic configurations, which was great in terms of flexibility but pretty complex when it came to selling.
When the T-Rex zSeries 990s were announced in May 2003, IBM wised up and did a few things to make its life easier, not the least of which was using dual-core processors in the mainframe TCMs and radically simplifying the mainframe product line. The T-Rex machines employed the z8 processors, which eventually ran at a top speed of 1.2 GHz and delivered around 450 MIPS of processing capacity (IBM said on some workloads, it looked more like 480 MIPS).
Unbeknownst to anyone at the time, according to Anzani, the T-Rex processor cores were all dual-core chips, but because IBM was getting very low yields on these processors, the design in the T-Rex boxes was such that for 8-, 16-, and 32-processor systems, only half of the chips in the TCM were running in dual-core mode.
The other cores on half of the chips were duds that had an imperfection that did not in any way affect the performance or operation of the other core on the chip. (This is an ingenious way to make the most of a new chip-making process and low yields as that process gets ramped up.) So with T-Rex, there were four dual-core chips and four more dual-core chips with only one functional core working for a total of 12. These processors had different functions, as I will explain below.
IBM wanted to move to dual-core mainframe processors for the same reason it had done so two years earlier in its Power RISC processors. Going dual-core packed a lot more oomph into the same processor socket, and usually generated less heat that two standalone chips. But the zSeries processors and their TCMs are complex machines, and yields were not high enough on the dual-core z8 processors so that IBM could jump to them directly and fully deploy them, putting 16 cores in a TCM.
The T-Rex machines were promised to come with 8, 16, 32, and 64 processor cores (including processors used as spares and as dedicated I/O processors). IBM shipped the 8-way box almost immediately, and got the 16-way and 32-way boxes out the door in October 2003, and was supposed to get the 64-core box out the door in late 2003 or early 2004.
With the T-Rex mainframes, IBM moved to a book packaging technique that put 12 processor chips on each TCM. Each different model of the T-Rex corresponded to having an additional processor book thrown in the box. When you get to four books, you are out of capacity, which in this case, turned out to be 9,060 MIPS.
On each T-Rex book, eight processors could be activated to do real work, either running z/OS or another mainframe operating system, or Linux through the VM-based Integrated Linux Facility (ILF). (With the zSeries 890 midrange mainframe, which was announced in the early summer of 2004, IBM added special engines dedicated to processing Java workloads called the zSeries Application Assist processor, which was backcast to the T-Rex boxes.)
Two of the extra four processors in a T-Rex book were assigned as System Assist Processors (SAPs), which are used by the channel subsystems and which handle system I/O, and two of the extras were designated as spares in case a primary active processor fails. Any unactivated processors in a T-Rex book can be activated as a coupling facility (used for Parallel Sysplex clustering) or as SAPs.
They can also be activated on an on-demand basis to support z/OS, Linux, or Java workloads. Each book could support four 8 GB memory cards, which meant a 64-way server would support 256 GB of main memory. Now, when IBM says 64 processors, be careful. That theoretical 64-way T-Rex machine, which would have offered a single system image size of only 48 cores running the z/OS operating system because 4 out of the 12 were designated as spares and I/O processors.
According to Anzani, with the System z9 books, IBM has made some tweaks to the z8 core to make the z9 processors. They are not just a crank on the clock, although IBM has boosted the clock speed to 1.7 GHz, which in turn boosts the mainframe capacity of the processor to around 580 MIPS. IBM has also done something very clever: It has allowed the two hot spare processors in the first book in the machine to be hot spares for any book in the machine.
The T-Rex machines had 12, 24, 36, and 48 total processor chips in their 1, 2, 3, and 4 books for a total of 8, 16, 24, and 32 usable processors for workloads; if IBM had got good yields on the dual-core z8 chips, the most powerful T-Rex TCMs would have been completely dual-core, not just half dual-core, bringing the total processor count up to 64. Taking out the SAPs and spares, leaving 48 processors to do real work.
With the biggest Danu mainframe, IBM has got all cores running in dual-core mode, making good on its plan for the T-Rex way back when. Even a few months ago, the word on the street in mainframe circles was that the Danu machines would top out at 38 active cores running at between 550 and 600 MIPS.
But, according to Anzani, IBM was able to pull forward the revised plan to ship at least the high-end Danu TCMs with full-on dual core processing. IBM’s largest mainframe shops want to consolidate a lot of workloads on their machines and make use of the logical partitioning and load balancing capabilities of the box, and they need more cores to do that.
There will be five models in the Danu mainframe line, officially known as the System z9 109 models S10, S18, S28, S38, and S54. The numbers tell you how many processors are available to do active work. The lower four models are similar to the existing T-Rex machines, except you only need two spares in the whole box, which frees up 2 processors in each book. (Each book needs at least two SAPs for I/O, however).
These lower four models (which have half their chips running in dual-core mode, and half in half-dud mode, like the T-Rexes) will begin shipping on September 16. The S54 model is expected to start shipping on November 18, and will include TCMs with all processors running in dual-core mode. This behemoth will deliver a total of 17,800 aggregate MIPS of capacity on z/OS workloads, which is a stunning amount of power in the mainframe world. IBM does not supply list pricing for mainframes, but I will be talking to the experts to see what they reckon these machines cost.
The Danu mainframe is expected to support up to 512 GB of main memory and has had its aggregate memory bandwidth boosted by 80 percent to 170 GB/sec. The machine will support up to 336 2Gb/sec FICON channels and up to 1,024 ESCON channels; parallel channels were last shipped on the zSeries 900 Freeway boxes in 2000. z/OS 1.4 or higher are supported on the Danu boxes, and IBM is shipping a new z/OS 1.7 release on the machines packed with all kinds of goodies.
