After writing about storage performance and various bottlenecks the tool that we have been using in Sun vdbench and SWAT (Storage Workload Analysis Tool) is now open source and generally available to the public. If you really want to know what is going on with your disk and tape storage this is what you need. Many give you nice pictures but not many that I have used over 20yrs gives this granularity. e.g. you can see how different disk array designs work depending on their cache algorithms. Also what happens when you want IOPS (small blksizes but many I/O's), or bandwidth fewer I/O's with

You can take your application find out what blocksize it uses, the proprotion or reads vs writes and then tell vdbench to write as many as possible to see where the performance of your storage device reaches saturation. The product is very feature reach as are the outputs, you can see the results using SWAT.

This has been extremely positive with all the customers that we worked with and used this together. Top tip what we did on a large screen is have the app on one window, vdbench on another, array performance monitor on another and SWAT on the next, SAN performance monitor on another. As vdbench emulated the applciation I/O we could see how the storage, server etc behaved.

You can get them from the following links:

Swat 3.00

Vdbench 4.07

This runs on Solaris, Linux, Windows and other systems.

Please use many have asked where to get it before.

Well done Henk Vandenbergh.

Well what I do is write my blogs when I get an inspiration, this most often is not while I am in the office. Most of it is while I am travelling in trains, planes, automobiles. So 3 blogs today, however, they were stored for weeks and months when I wrote the draft in some airplane or remote location.

3 blogs in a day, I am catching up to my lost quota of 1 blog per week. I still have 10 saved up over the months.

The marketplace and hollywood have very restrictive views and impressions of the mainframe and many believe that IBM are the only ones that can supply such a thing. Well in reality the mainframe does not exist only in the minds of marketing and fiction. As many suppliers nowadays have equivalent and/or superior mainframe systems to IBM's.

Everyone who has not worked with mainframes has this impression; they are large, expensive, fast, complex, special, adaptable, reliable.

Everyone who has worked with mainframes knows the following; they are large, expensive but will be discounted on the hardware to make them look competitive, but software charges and maintenance will be expensive, they are not fast anymore or no faster than any other large system, you can only run zOS (MVS), they are not complex just totally proprietary. Not really adaptable, everything needs to run on the zOS instruction set need hypervisors (read overhead) to do conversions to run other interesting OSes like Linux, really good for the old stuff like CICS and old batch programs that no-one understands as the people who wrote the retired. They are special as a whole load of emotional baggage goes with them, companies cannot migrate from them as no-one understand the apps, so companies are held hostage, costs are often hidden in various ways (s/w, maint, service) so you can never get to the bottom of the TCO. As for reliability no different than any other major large system where you have good change control. Mainframes have good reliability records as no-one is allowed to change them. If you have other high end systems that you do not change they will be as reliable as a "mainframe". The mainframe hardware is not special compared to other high end systems. Historically they were better about 10yrs ago, but this myth continues.

So we either stop calling the z10 server a mainframe or we call every high-end server a mainframe. Sun and IBM high end Unix mainframes (servers), (not sure about HP, SGI etc) high end servers have better or equivalent features to the z10 servers.

Mainframe acid test, ask IBM what is the best plaform for every application that you want to run, what is the difference between their Linux actually Red Hat, AIX and zOS offerings. Is AIX inferior to zOS (aka MVS), is Red Hat not as good as AIX. Is Red had better than zOS. When should we use what.

Can I run Red Hat on a p-series
Can I run AIX on a z10 mainframe server (apparently it uses the same CPUs)
Can I run zOS on a p-series.

I get really confused with the positioning and confusion of AIX, Red Hat and z/OS. When do I do what with what. Or do I just do everything with everything and make a real mess. Good fun for the techies.

So with HP recently they came up with some logical partitioning with something called Dynamic LPARs, well that is old established technology, nothing new here. Available from others and established technology for a long time. However, HP engineering was always good, HP used to be a engineering company initially. So their high end UNIX servers can also be looked upon as mainframes.

Now Sun M-series servers have instruction retry, whole memory DIMM mirroring, crossbar ECC, more dynamic replacement of CPU's, RAM than any other supplier while the system is running and more. So you not get get more reliable than that and mainframes may not even have the reliability of some high end Unix servers.

Mainframe has been around since 1960's so the name is familiar but missused. Like many things in life, understanding, education and knowledge helps dispell these myths when once upon a time long ago they were something special. Now I like the mainframe, love to tune the assembler code, patch and zap modules, good for your old apps that no-one understands and your company is too scared to migrate to a new lower cost system. But as with everything technology moves forward and other high end systems especially large Unix servers are just as good or better and can be understood by more people.

The holy grail of storage performance, here goes (this question comes up every week).

To make I/O performance perfect, a block of data needs to be transferred, unhindered and unaltered with as few dissasemblies and assemblies as possible as it travels from the CPU to the physical disks. I have explained this many times and tuned this for over 20yrs and the basic rules do not change, strange thing. Neither do Moore's Law or Amdahls law, but they do get misquoted.

So if you application writes in 16K blocks make sure that all components in the I/O path for this application work in 16K units or larger. But not too much large as you will be wasting resources.

-- Exceprt from a discussion a couple of weeks ago, when an app was writing data in 128KB blocks and we were using a shared HPC SAN fielsystem called QFS, may be useful to someone ---

Suppliers (array manufacturers), industry etc mix up segment size and stripe width. This is what I do:

Understand you disk arrays and how they transfer data.

segment size is size of block write on a individual disk (your case 128KB)
stripe width is the amount that the array controller writes to a raid vol/grp/unit, this is number of disks x segment size (your case 128KB x 4 = 512KB). Person was using 4 disks.

Now the DAU (Disk Allocation Unit) that QFS uses to write a block of data for most best practices should match this to avoid write/read miss and what we want to do is for one QFS read or write you only have one "RAID group" read/write. But you can specify the DAU to be what ever you want, within reason.

Your application is writing data in blocks of 0.5MB, So yes your DAU should be 512KB.

So you can have 4 disks of 128KB seg size, or 8 disks or 64KB seg size etc. 8 disks will give more performance than 4, and if you have a 8D+1P RAID 5 group this just happens to fit nicely. NB 1 disk is for RAID parity so you need to add this to the 8 disks for data.

Remember no matter how good a disk arrays cache system is, with the sizes of databases etc that we have nowadays the cache can get overwhelmed very quickly if you do not have enough spindles or disks as we call them. In the end performance is determined by the number of IOPS (I/O's per second) of the backend disks. Try a database load, import/export of a table and watch you disk array performance deteriorate as the cache just cannot keep up.

Now IOPS, very approximate rule is that the faster the disk spins the higher will be it's performance. However, if you can get the average seek time and rotational latency from a disk manufacturers disk sheet then you can work out IOPS. IOPS can be calculated by using the following formula;

IOPS = 1000ms/(averag seek time + rotational latency)

Now QFS stripe options can also help here, but that is an even bigger story. QFS can do round robin writes and stripe accross many disk array RAID groups/sets.

The trick is that the DAU is (most of the time I am sure there will be exceptions) the same blocksize (currency) that the app uses. e.g app writes 950KB DAU should be 1024KB. Most apps behave in the normal powers of 2 KB type (8,16,32,64,128,256,512,1024,2048) thing so you should have a close match as DAU's can be the same size.

What we try to do most of the time is to configure the system so that all the "gates" from the app to the disk raid group are the same size. The "truck" i.e. the block of data fits all the way from the app to QFS filesystem to RAID group without having to do 2 or more writes/read for one requested block for the application. Nightmare scenario is that for an app writing one block the array does many writes. e.g. app writes 128KB and stripe width = 32KB, thus everytime the app does a single read or write the controller has to ask (read/write) 4 times. This is serious I/O performance overhead and what I can make lots of money fixing.

Make sure that your block is not disassembled or assembled in it's journey from the app to the disk. OK the PCI bridges and HBA's may do this but we cannot change that. PCI lanes is getting into deep heavy tech stuff.

So I normally work this way. Find the app blocksize, then make the DAU the same, then make the stripe width the same as the DAU, then decide how many disks we want to use to get IOPS and then divide the stripe width derived from the above calculation by the number of spindles in the physical arrays raid group, to get the segment size. Now the segment sizes are mainly fixed on the arrays that we use, from 8,16,32,64,126,256KB. So we sometimes do not get a round number, to match the app blksize, DAU etc. However, I always make this "magic gate number for the blocks/trucks" larger than the DAU so to avoid 2 physical reads/writes per each application write/read, which is the crux of all application and I/O tuning.

Storage heaven is where we have full stripe writes and reads. Which is implied by the application block size, DAU fitting the stripe width accordingly.

You can check this with various tools by using vdbench (storage perfromance saviour) to do 10 writes or reads of a specific blocksize and if the array does not do the same amount of I/O's (e.g. 10 writes/reads) then you are not hitting the G spot (array Group Size) spot. So if you do 10 writes and the array did 20 your seg size quite likely is half of your DAU or app blocksize. Remember filesystems do strange things to application writes and can mutilate them in more ways than we can dream up, so we have to know and understand filesystems. A good old Unix test is the "dd" command, if you have a array with a certain number of disks in a RAID group run dd to the actual raw Lun to see what it can do. Your filesystem layout which you use later if correctly tuned should get close to this number. If you get more then you are a candidate for a Nobel prize. If widely different then something between the app and the disk is messing thinks up. No chance of a Nobel prize, maybe a Darwin prize.

Think of a truck going down a road and all the tunnels and lanes are the exact size or bigger, thus the trucks journey is never hindered and the driver does not have to unload/dissassemble, load/assemble the truck (block of data) to get it through the tunnels, lanes, toll gates.

Now can the QFS community guys check this as I have been know to write faster than I think. But have have got close to max specified speeds on 6140 and 6540 using this technique. Plus some old heritage and legacy arrays.

Now Have I put the whole storage consultancy business out of a job. Not really, take this example. A woman calls a mechanic (call him Jerry) to fix her car as the engine does not work. Then Jerry takes a look at the engine and gets a hammer, he hits a specific part of the engine and the engine starts to work. Jerry says, that will cost you $500. The woman says, you must be joking, you just hit it with a $10 hammer. Well says Jerry, the bill is for $10 for the hammer and $490 for the knowledge where to hit the engine. You pay for knowledge not the muscle.

We had a customer using an application on a customer platform, the supplier wanted funding from the customer to re-write the application to another Unix. Sun recommended to use Dtrace to find the areas that could be improved and help the ISV move from Solaris 8 to Solaris 10. However, the application supplier said that it would take too much work/money etc, it would cost less to re-write to another unix.

However, the OEM wanted the binary compatability value offered by Sun and to exploit Sun's multi-core chip technologies. So when the customer officially requested that the ISV work with Sun to determine if the application could be moved to Solaris 10, we discovered some interesting hidden agendas. Sun together with the supplier very quickly found areas in the application code for improvement at a fraction of the time and cost of a port to another platform. Application performance was improved by an order of magnitude, 10 x faster and qualification onto Solaris 10 was not a problem. Costs of taking the Solaris 8 binary compatible code, tuning it with Dtrace and moving to Solaris 10 were a fraction of re-writing to another platform. So beware, people may want funding to move applications to platforms, then ask for more money later to support a myriad of kernels. However, with Dtrace they can improve performance dramatically and shorten the time to qualify Solaris 8 & 9 apps onto Solaris 10. Buyer beware, the reason for not moving to the latest release of Solaris may not be technical.

By the way we also consolidated several servers runing this application onto one M5000 using Solaris containers to run many virtualised instances of the application. Ended up with nearly 100's of applications running on one server. The customer could now reduce the number or racks that they needed to.

Carzy world, moving applications from Solaris 8 to Solaris 10 is easy and you can consolidate your servers at the same time. Madness where will it all end. One big computer.

Make sure that all ISV's and application providers know the benefits of a faster time to market and reduced development costs that Solaris and Dtrace can bring them. Costs too much to qualify on Solaris 10, what a red herring. Make your application faster with minimum investment, use those Dtrace features. It is the developers best friend, I wish I had such a tool when I was a programmer.

The moral of the story is; All end users, ask your application suppliers or Sun to validate application qualification to the latest release of Solaris with Dtrace.

Why does this remind me of some builders when you are renovating your house. When they say "that will cost you", in reality it is a much simpler job. Maybe that is why the DIY business is so profitable.

Desktop PC's and laptops are called rich clients today as your company has to be very rich to run them. As shown many times thin clients reduce power consumption, reduce maintenance costs, improve security, make disaster recovery, backup & restore faster/simpler etc. I know many customers where they have 2 admins and 2,000 thin clients, instead of 10 admins to 2,000 laptops/PC's. Desktop PC's and laptops used to be called Fat clients but the marketing departments quickly changed their name to rich, now is this because they cost more to run.

People want fat clients so that they can do their work if the network is down, however, how many of us really move around. How often does your companies network go down. Network outages is not one of the problems or recurring issues that I see nowadays.

With laptops if we want to show others our work, we email them the data/pics or docs, or we walk around the building with a laptop to a meeting room. The network is your feet. Sending/rather than sharing the data just causing the extra storage management problems. Walking aroung with laptops is a pain, I have seen many people who no longer do this as carrying laptops to/from work gave them illnesses like "tennis elbow" Yup, I did not believe it when I first heard about this either.

With a thin client Sunray we can also email all data, or just walk to other persons desk take their card out of the thin client on your desk and insert your card and they can see your data. No heavy laptop, no transformers to carry no muscle strain.

Now some workers need laptops, but if your company truely does some analysis who is mobile and who sits behind the desk all day, maybe 80% of your employees do not move so a thin client will be best. Fat clients for those that move around.

Laptops are no longer called fat clients, as the people who carry them around have lost weight and are no longer fat. I'm still fat as I work from home and use a thin client SunRay at work, but I did cycle to work today.

Like most issues logic is not that important, in medieval europe and in lesser developed countries being fat was a sign of power and wealth. With laptops when they were new it was also a subconscious sign of power, wealth and latest tech. Nowadays, being thin and being able to eat less fatty food and having the time to excercise is a sign of wealth and power. Thin is fashionable. With fat/rich clients will we have the same development, a person with no laptop has power and wealth as someone else carries this for him. Maybe a small hi-tech mobile/pda will be the next sign of wealth and power.

Technology as many things get warped into fashions and lifestyle choices. Crackberrys are another interesting phenomenon.

Written on a SunRay which is connected to a HA-clustered server in a unknown location.

We have been trying for years to use less resources in the datacenter and use air cooling, now we are putting more water cooling into our server designs. I cannot see this as a technological improvement. Again we are curing a problem that should not have happened in the first place. We need to solve the problem in the first place, that is do not make CPU's/chips so hot that they need to be water cooled. We are just making computers so much more difficult to manage by adding water cooling within servers.

Problems with water cooling within computers.

1) Complexity (need water in addition to all other cabling within datacenter)
2) Extra costs (any addition to electicity water cooling requires additional power in a datacenter, which adds costs)
3) Safety (water and electricity are a dagerous mixture, always a risk of water leaks)
4) Increase management (need a whole extra water cooling infrastructure and pipework)

I know that history has a habit of repeating itself, however can we not improve upon designs and techniques from the last century and make cooler less hot chips.

Prevent hot chips, hot CPU's are a design flaw. A cure such as water cooling always costs an order of magnitude more than prevention of the problem in the first place.

A green datacenter should not have water cooled computers. Anyone using this water cooling to heat the building is adding immense complexity. What happens when we kick out the water cooled computer, do people in the building freeze. If we have a water pipe leakage do we have to swith off the water cooled computer while the rest of the air cooled computers continue running. Water cooling computers just have too many downsides and add so much more complexity. We can make life more simple by avoiding water cooled servers and using air cooled systems.

I started work with old IBM mainframes, Amdahl, Hitachi etc. There were always extra problems with water cooling much more to go wrong. Now do we really want to have water pipes all over the datacenter. Not really, ideally we try to have less cabling, pipes etc. That is why it is better we have protocols and cabling improvements like FC, SAS, 10GigE with increased bandwidth and hopefully less to manage. Now we add water pipes in the computer room, it was problematic and costly 20yrs ago and still is.

As all electricians know, water and electricity are a lethal mixture. Avoid water cooled computers.

This presentation is one of the best explanations and simple examples of what needs to be done to reduce our carbon footprint in order to stem global warming. Food for thought as we may need to eat less meat

There are two ways to solve a problem, don't cause the problem in the first place, or solve it once you have a problem. Prevention rather than cure, type methodology.

I like to avoid the problem in the first place as it costs more to fix than to avoid, hence my like for low power computing with thin clients , cool servers and low energy storage .

This speaker was excellent, I have not checked his numbers but it made me think

While looking into all the mainframe claims we (Jeff Savitt) discovered, lots of incorrect comparisons that were used when comparing new mainframe systems to 2-3 year old Unix systems (new with old comparison). Well a colleague in Germany has just busted another rather silly comparison, albeit for a new Unix servers to old Unix comparison, you can see the write up here.

Now I speculated that the equivalent amount of rack space of Sun Niagara servers e.g. T5220 would be able to successfully consolidate (1250 per rack) more servers than a mainframe, note the term successfully. I remember a while ago some very large mainframe Unix/linux consolidations failed.

This article is well worth looking into, the power and cooling characteristics of the T5220 will definitely have an competitive edge over the lifetime of the mainframe especially once you take into account the cooling and power requirements of the mainframe. Plus you can start small with the 2U T5220, and build in low cost pieces with one small T5220 at a time. With the big iron mainframe, cost of entry and cost of exit is very much more expensive.

Anyway thanks to Joerg in Sun Germany for another very good and simple explanation of more realistic and sensible comparisons.

Many people think that technology is not important and that it is a commodity. Well there are two parts to this, those that want to cut costs and treat IT as a cost center. This article is for you. For those that want to use IT to beat the competition, which is what computers were designed to do for companies in the first place, that blog will come later. However, recently this very good article appeared. Here is and example where tehcnology is important as it can save you money, power, cooling and management costs, while improving security.

Standard office over last 15yrs with PC's (last century computing model).

Desktop PC on or under each desk.
Each has a transformer/power unit built in, normally between 300-800 Watts - which means lots of power required.
Each has a hard disk built in - which means lots of local data to back up, and a security issue to protect.
Each has a CD, DVD or maybe a floppy disk built in - which means even more easier to steal data.
Many deskstops will be different thus requiring different drivers/maint fixes etc.
PC's are left switched on overnight - which means a waste of company money/power (even when on standby).
Each PC has it's own CPU, many systems in your company will mean many different speed and type of CPU, more complexity and management, plus wasted rsesource as they are so underutilized.
Each PC has it's own operating system - which means a lot of complex managment required to maintain and update (means more costs).
If you have a laptop, you need the network to do most of your work, but you better make sure you do not loose your laptop and it's data.

Mobile workers may need laptops and that is OK, but if you count the people in your company who always sit at the same desk everyday, those are the ones who do not need a company laptop.

Often you need many admins to manage these, if a desktop PC fails the time taken to replace and restore all data is hours or days.

I base my security theft assumptions on the fact that most security breaches and losses of data are due to internal process and people.

Thin Client or a Sun Ray (true thin client with no local data) which can present (run) Windows apps. This is what I call the new millenium computing model. Big picture so that you can see there are no tricks here.

Small unit size of a large pocket book on desk.
Small transformer up to 100W (actually 5-10W usage. Thus save you r power bill by 90% straight away. ROI case solved.
No hard disk - whcih means no local data to backup, no local data to steal. Security problem solved.
No CD, DVD or floppy - so nothing to steal, no security required to manage. Security solved, again.
No local drivers required as the SunRay thin client has a network card and graphics chip.
There is no local CPU , fan cooling or anything like that, much less power usage even when left switched on.
No local operating system. Thus upgrade & maintenance costs reduced by orders of magnitude.
SunRays come with Wifi connections, so if the network goes down it is easy to get another connection. If a disaster occurs it is easy to move to another building which has the half of the data and work can start very quickly from the point where you left your work. All you need is your ID card to sign in, or your password.
In a disaster we do not have to restore 1,000 of PC's but just one server, ideally the backup server has all the data in another site already and work continues. No great drama or crises here.

Sunrays are not for mobile workers. How many of us are mobile anyway.

If the SunRay fails, you can replace in minutes or hours, no data to restore, as there is no data locally. So you can use one of these SunRay thin clients and keep your present screens or buy whicever you want, the SunRay uses standard screens. Big pictures so that you can really check it out.

This needs 1 x power connection, 1 x network connection and 1 x connection to the screen, mouse and keyboard, if all goes wrong it takes 2 minutes to replace. Uses about 4Watts of power and has no moving parts and totally silent. It is the height of a paperback book and you can see a credit card size ID card that you can insert to identify yourself to any Sunray in your network/company. As you can see you can have microphones and speakers connected if you really want to. You can take it out rush upstairs and put it in your bosses Sunray and he can see exactly what you are working on. Great when people are changing over between presentations.

So technology is not important, one requires lots of maintenance, power and takes a long to replace if broken, plus horendous security issues. The other technology solves all those business issues.

Have a look here to see how you can get a competitive edge.

I do not want people to get the wrong impression, I had some very good times working with the mainframe and I learnt a lot. However, time moves on and I moved with the technology developments to other platforms.

This is very similar to my favourite old car, that was a Saab 9000, 2.3turbo, Anniversary Edition. It had leather seats, wooden fascia, quiet, fast and safe.

I often would still like to have it but for todays requirements it uses too much fuel and would probably start to get too expensive to run. Since that car I have had a Toyota, Saab 9-5 and an Audi. I have choice of the open marketplace, if I stick to the old Saab 9000 I am locked in. Which is never a good thing.

So bottom line, we look at the mainframe with good memories but we need to move forward and adapt to new technologies. We need to let go and adapt. We cannot tow around our old cars with us forever.

The other argument is that that the mainframe is adapting like the Saab 9000 to 9-5, as we get new models. But the new car models do not need to pull or tow along the old models. The problem is that z/OS which comes from ESA, MVS, MVT just keeps on getting add-ons. But it is still has to support all the old apps, mainly based on a batch processing system (which no-one can understand anymore), with some bits to make it run OLTP, Linux and all sorts of goodies (read complexity). Also the CPU's still need to run the S/380, S/390, ESA/390, z/9, z/10 and more recent version of this instruction set, of which there are 100's of old instructions. This is why it is called a CISC processor, Complex Instruction set computer. In comparison to simpler SPARC and Power RISC Reduced Instruction set computers. So we have one hell of a level of complexity with mainframes running complex instructions on RISC processors or derivatives thereof. Now this is interesting and fun for the geeks, but not really for business. As all programs/applications have to go through many levels of instruction abstraction/translation etc. Basically mainframes due to their history have immense complexity. Complexity means costly management and difficult problem determination.

I would have loved to have stayed with the mainframe all my career, it was fun, I was quite good at it, people I worked with were great, but many others also moved to UNIX and open systems. Back in the 1980's I actually believed that I would be working with the mainframe for the rest of my career, but then I was young and there was only IBM and DEC. Chips also changed from Bipolar to CMOS, which made it easier for competition. Now the old heatsink/towers on Bipolar chips look not too dissimilar from all the heatsinks we now need on our PC's sad, that is why Sun coolthreads CPUs are cool. However, technology and the world moved on and the mainframe tries to re-invent itself. While carrying all it's historic baggage, which is some weight that we need to burden ourselves with. So like an old shoe, you can replace the soles so many times until you just have to get a new pair. Sometimes we have to try a new pair of shoes or a new design.

IBM compares new z10 mainframe with 3-4 yr old Sun servers and makes their own old mainframes look slower. Now I worked with the mainframe for over 10 years, COBOL and CICS and all thoses thing were great. However, these type of comparisons devalue the mainframe. We need to compare new products from one supplier (IBM) with the equivalent new and current products from competitive suppliers, Sun etc. Quote from IT Jungle article "Last week, with the launch of the System z10 Enterprise Class mainframe, the mainframe is as close to parity with big Unix and proprietary RISC machines as it has been in a long, long time." But can IBM keep this up, the mainframe lost competitiveness about 10yrs ago and the UNIX mainframes will not stand still.

Not sure about the proprietaty claim either, SPARC CPU designs are open source and have been for over 10 yrs, see OpenSparc. Also Fujitsu use the same CPU's. So Sun has other companies using their Chips, I do not know of another company using the IBM chips or IBM CPU designs being open source. I am afraid that Sun is not proprietary but many other companies are. This is an old pre-conceived view.

Also, I thought that the industry has started to understand that CPU speed i.e. GHz is not a good indicator of performance, with all the claims that IBM is making I would like to say that the equivalent amount of T5220 (8 core, 64 threads with 1.4GHz) servers that take up the same floor space, power and cooling as a IBM z10 will be able to can consolidate more smaller systems while maintaining performance and improving availability and management than a z10. Solaris has in-built virtualisation with LDOMS and containers that is free and open source. Now what would the IBM z/OS costs for this be, people really need to look at this area?

Strangely I just read in this article that IBM has caught up with large UNIX mainframes with their z/OS mainframe. However, this article got some very simple technical details wrong. Large Sun Enterprise Servers (which have all the features of mainframes and more) e.g. the M8000 and M9000 series use up 64 x 2.1GHz and/or 2.4GHz dual core CPU's. You can have up to 64 of these dual core CPU's in one system. Now what we can do in these Sun UNIX mainframes is mix CPU speeds, so if by any chance we have a new faster CPU becoming available in the next 6 months, you can add that to the system while it is running. Now that is innovation and investment protection.

So this claim from the article; "That extra clock speed is important since the 4.4 GHz clocks IBM can now deliver in the z10 give it an edge over the 3 GHz or so clock speeds of X64 alternatives and the 1.6 GHz to 1.8 GHz clock speeds of the Itanium and UltraSparc-IV+ processors used by Hewlett-Packard and Sun Microsystems in their big iron Unix boxes." Is just becoming less relevant.

So IBM is comparing a new z10 system with some old Sun System. These M-series large UNIX mainframes have been available for 10 months now.

As a colleague Jeff Savit wrote in a very good article, IBM is comparing their new products with competitors old products a very sneaky trick and not very honest. Thus this shows that we have to be very cautious about any of the claims in this announcement. This article is a must read for anyone who wants to understand the IBM z10 systems claims in comparison to Unix mainframes.

There is another very strange performance comparison going on here, so that the new z10 can look better, This article implies that the old systems are now specified as being a lot slower than they really were. From the same article here is the quote. "IBM's documents for the z10 say that the fastest z6 core is expected to deliver 62 percent more performance than the fastest z9 core, which had a much lower clock speed. (That would seem to suggest that the 1.7 GHz z9 processor core running full out should have been rated at 568 MIPS, which is lower than the numbers a lot of people have been throwing around for three years.)" So not only does IBM not compare latest z10 mainframe server with old Sun servers, but they compare and reduce the performance numbers of the older mainframes. If I was a IBM z/OS customer I would ask for a refund on the old system software licences as the MIPS value has just changed, since the old z-series was not as fast according to the MIPS indicator as IBM said it was.

Summary, the truth is coming out out slowly, so buyer beware, look at these mainframe claims very, very closely and be suspicious.

I have the greatest respect for IBM, but there are just too many strange claims being made here. After all IBM together with Toshiba (I think) made the cell processor that we have on the Playstation 3. Now that IBM cell chip is really interesting. I cannot say the same about the z10 mainframe with all thes strange comparisons going on.

Just as we expected, the best place for the new mainframe is to replace old mainframes, not Unix (Linux) or other non-mainframe systems. This comes from a end user/customer who admits exactly that, you can read it in this search datacenter article.

But here is the quote "Though IBM has pushed hard to present the mainframe as a consolidation target for hundreds, if not thousands, of virtual Linux servers, Handera saw the new machine as a boon to better handling more traditional mainframe applications such as DB2, WebSphere and CICS batch jobs."

So get rid of the old mainframes and migrate them to the new one. That way you can save costs. During the migration project, you may be able to take some applications off the mainframe and run it on another more open and cost effective and open system giving you more choice and options in the future.

As you move from an old mainframe you often find systems that do not need to run on there anymore, faster, newer and more cost effective Unix servers for which you can do open bids are often more efficient. So it is good to do a review now and again on how you can reduce your zOS dependence.

Remember if you look for a new mainframe, only one company can give you a price. If you want to buy a new mainframe/Unix server you have several suppliers.

Mainframe market is a monopoly, thus you will pay monopoly prices. Do not try and stay dependent on a single supplier, this is not good for business. Shame that we do not have Amdahl and Hitachi making zOS mainframes/servers anymore.

The IBM mainframe is good for running traditional MVS or z/OS apps like CICS and batch jobs that no-one can understand anymore. If you want more mainstream IT stick with UNIX mainframes.

Well we have an old, new mainframe again. I spent a lot of my time with mainframes but moved on when I saw the mainframe market going down, I also felt that I had done as much as I could so I moved to working with Unix, specifically Solaris and HP-UX.

Now there has been a large amount of FUD about this announcement. Some thing that I would like to put straight.

Consolidation - The Mainframe is good to consolidate other mainframes but not really other servers. So if you have 2 or 3 old mainframes that you cannot get rid of. Consolidate them into one of these new ones. Make sure that IBM can show that it will be cheaper to run one mainframe than 2 or 3. Then check the numbers very carefully and do your own research. About consolidating Unix (Linux) servers into a mainframe, now that is a big leap of faith. People should be very careful with this proposition. Should not IBM get more applications developed for z10 and zOS, Open Source z/OS to get better mainframe adoption. This IBM linux consolidation sounds like a desparate cry of help for the mainframe.

IBM mainframe consolidation problem number 1, if the z10 system needs to be serviced including an outage, you will have all your Linux apps out of action. Now IBM will then say buy 2 mainframes, oh dear. Best to stay where you are and consolidate in smaller more manageable and serviceable chunks.

Mainframe big/fast box - I do not believe this for one moment. The large Sun and IBM Unix servers are faster and probably a lot smaller than this old/new iron.

Reliability - The mainframe lost this years ago, Sun and other High end Unix mainframes/servers are just as reliable. The mainframe may be more reliable as you only run your old apps on them which you never change as no-one understands them anymore. But then which server would not be reliable, if you never interfere with it. There are many examples of Sun servers running for several years without a reboot and departments forgeting about them as they "just run forever".

Scaleability - Sun and other large mainframes/Unix servers scale to equivalent or larger systems. Nothing new here for the z10.

Performance - The MIPS algorithm or Meaningless Indication of Performance. Is really a red-herring, you can compare a old mainframe to an new, old mainframe using MIPS but it is not really useful for comparing mainframes with other server platforms. TPC-D type benchmarks are better than MIPS, but still is not a definitive comparison. Companies do not make money running TPC benchmarks they make money running applications, which can only partially be compared using benchmarks.

Innovation - Presently from the information that I have available, the new Z large server (aka mainframe) uses 2 dual core P6 CPU's on a module/circuit board to make it look like a 4 core system. Well you can fool some of the people most of the the time but not all of the people all of the time.

I see that I will need to spend some time looking at this mainframe stuff in detail.

Well I was never clever enough to go to Oxford University, but as one of the worlds leading education establishments for the last 400yrs they must be doing something right. That means that they are thought leaders and we should listen to what they do, well I always preferred the teachers at school who sounded like they had done what they were talking about. Here is an excerpt from a yahoo newsflash " By using Sun Rays across all university sites, Oxford is saving roughly $10,000 USD per year on power, reducing heat generation, cutting administration time and much more.", The whole article is here: Oxford University saves $10,000 of power costs.

So Oxford university has just saved loads of electrical power, improved security, provided more desk space for people to work, made it easier to maintain and swap any equipment.

You can change a SunRay in less time it takes to order a pizza. I call this Pizza service time or PST. It must be pretty good and not just a Sun idea as Wyse and other are copying the SunRay thin client idea.

No data is stored locally but is on a cluster of server computers, thus no need for laptop/PC backups or restores. Also, no data to be stolen locally, thus many of your security problems are solved.

And they do not need to add more cooling and refigration as the thin client SunRays use less power than Laptops or PC's.

Remember thin client SunRays provide access to MS windows applications as well as Unix applications. Now there is a interesting fact that many do not know about. (I was corrected that the application runs on the servers, but we all knew that, this is why I never got into Oxford or Cambridge).

I was always a bit more of a techy and I did live closer to Cambridge than Oxford, so I had more of a preference for Cambridge University. However, I was not smart enough to go their either, but then again I never applied. Now what is Cambridge doing in the area of smart computing.