The IT Business

Manchmal finde ich es dann doch erstaunlich, wie wenig Ahnung manche Leute der Blogosphäre ausserhalb ihres Fachgebietes von der praktischen Seite der IT haben: Schönes Beispiel ist hier Fefe:

Die RAM-Hersteller (wahrscheinlich nur die chinesischen, nehme ich mal an) lassen ihre RAMs durch die Qualitätsprüfung fahren, und die RAMs, die das überstehen, die gehen in den Export nach Amerika und Europa, und die anderen verscheuern sie dann billig in den Schwellenländern, wo die Leute sich die Export Grade RAMs nicht leisten könnten.

Und wenn ihr das hört, dann denkt mal darüber nach, dass RAMs ja auch in embedded Computern drin ist, wie sie aus China kommen. Man muß da gar nicht über medizinische Geräte oder Reaktorsteuerungen nachdenken, um ein schlechtes Gefühl zu kriegen.

Also, Fefe ... das nennt sich Yield Management und das macht jeder. Nicht nur der Chinese. Oder meinst Du, irgendjemand wirft 90% des Wafers weg, weil die Dies nicht perfekt sind?

Schönes Beispiel ... Prozessoren. Es werden da eigentlich nur die Topprozessoren gefertigt. Das Dumme ist nur: Chipfertigung dauert lange (mehrere Wochen von Waferstart bis Ende), es gibt Fertigungstoleranzen, unterschiedliche Kontaminationen in der Umgebung und das heisst soviel wie. Alle Dies haben eine leicht unterschiedliche Qualität. Alles was den Topqualität nicht besteht, wird einfach dann eingestuft in eine andere Qualitätsstufe. Wird im Volksmund auch Taktung genannt. Wo nen Core kaputt ist ... wird ein TripleCore draus. Für die Leute auch in den Industrieländern, die sich keinen Topprozessore leisten können. Das schöne ist: So kann man mehr vom Wafer verkaufen und hat ein abgestuftes Preismodell. Die nicht ganz so guten Cores zahlen den Wafer, die guten Cores den Gewinn.

Interessanterweise gilt: Je ausgereifter ein Prozess wird, desto weniger Schraddel produziert man. So passiert es oft, das man nicht genügend Schraddel hat, um den Markt zu decken. Was macht man also, man stuft eigentlich bessere Komponenten herunter, um den Bedarf zu bedienen. Bei CPUs und Speicher wird das dann oft als Übertaktungspotenzial genannt, ist aber aber eine Konsequenz aus dem Yield Management. Es ist also wahrscheinlich, bessere Qualität zu erhalten, als eigentlich gekauft.

Im Speicherbereich ist es das selbe: Man bekommt Speicher in "extrem gut, kaum Alterungserscheinungen,nahezu perfekt" über "haelt für normalen Haushaltsgebrauch im PC" bis hin zu "Läuft stabil bei halbiertem Takt". Letzteres verkauft man dann in Anwendungen wie Embedded, wo die hohen Anforderungen von PC-Speicher nicht gestellt werden und Speicher weit unterhalb von seiner Spezifikation läuft.

Klar gibt es da dann immer wieder Leute die noch mal nen Euro oder Yuan sparen wollen, und sich dann über ultrabilligen PC-Speicher freuen, auf dessen Platinen dann irgendeine Hinterhofwerkstatt den Niedrigqualitätsspeicher geloetet hat.

Und mal ganz ehrlich: Das was wir üblicherweise in PC hier in Europa als Speicher stecken, ist auch nur der Mittelqualitätsschraddel.

Wirkliche Spitzenqualität kostet mehr ... sehr viel mehr. Nur das passt nicht mehr ins Preisgefüge eines x86 und oftmals auch nicht in das Preisgefüge eines x86 Servers. Das ist dann eher für Leute, die sich Gedanken darüber machen müssen, das man in einigen Jahren noch Speicher austauschen kann, und der benutzte Speicher nicht soweit aus der Toleranz gelaufen ist, das er mit neuem Speicher nicht mehr laufen kann.

Ich denke nicht, das man da verwundert tun muss. Das ist Business-as-usual.

... you don´t need enemies. Sun has a good working relationship with Intel. Thus i would expect better articles like this one at the Server Room Blog. While i understand that a Intel guy wants to pitch the processors of his employer, i don´t understand why he talks about Solaris and AIX, when he really wants to say SPARC and Power. Okay, Power and AIX are dependent from each other.

But you can run Solaris at x86 as well and it runs especially well on Nehalem based systems. Ken Lloyd does the mistake of many people by thinking about Solaris: Thinking about SPARC when thinking about Solaris and connecting Linux with x86. When your cost structure mandates x86 your could easily use Solaris as well.

It´s the same RedHat tries to tell you: Obviously Linux on a brand new Xeon is cheaper when you compare with Solaris on an old E250 Server.

Ken writes:

It is reasonable to say Xeon can deliver better performance, better value, and equal or better reliability

I would like to answer to this quote with a quote of Jonathan Heiliger, the vice president of technical operations for Facebook:

The biggest thing ? was less-than-anticipated performance gains from new microarchitectures, so new CPUs from guys like Intel and AMD. The performance gains they're touting in the press, we're not seeing in our applications," Heiliger told the audience.

As the GHz race has ceased and the Intel/AMD fraction goes into multicores as well, they run in pretty much the same problem as Sun since 2005. Not every customers application is multicore friendly. And by the way:The Nehalem just got in the same range of per socket performance like the UltraSPARC T2 processor, a processor that hit the market in 2007. Does Ken really thinks that we don´t develop a successor to UltraSPARC T2? When you look at performance of SPARC just look at the SPARC64 VIIIfx.

10 GBit/s or crypto acceleration on die has to be seen on Intel procs ... so much to the "value" moniker. And Xeon is nowhere near to UltraSPARC T or even SPARC64 VII in term of reliability.

By the way: I find this reliability discussion on CPU basis really funny. Reliability is a systemic property, not a component property. Even the best CPU is helpless, when the system around it doesn´t hold to the standards of the CPU. A CPU can´t work in a reliable way, when you just put the cheapest memory from the spot market into the system.

The mentioned Machine Check Architecture architecture mentioned in the blog entry is just a reporting system of errors (something SPARC, Power and all the other RISC architectures do since the last century). It needs the OS to react on the error. So the dismissal of Solaris is really strange,too: Linux doesn´t have something like the Fault Management Architecture of Solaris, but you need exactly something like the FMA to take advantage of MCA.

Ken, the managers you mention as those negelecting the business aren´t idiots. They just don´t believe everything Intel, the Linux business and the media tries to implant in their mind without questioning everything. At last your article is just a good example for marketing piece trying to pitch the products of your employer by repeating the same stuff again and again. But that doesn´t make it true.

We should implement a new scheduling class in Solaris: The user-mood aware scheduler. There is already an scheduler in Solaris that increases the priority of a process by 10 when it´s in the focus on the GUI. But is this really a measure of importance. Let´s connect the the microphone of a computer with the scheduling! The harder you type on a keyboard, the louder you will hear the mechanics of the notebook. The harder you type on a keyboard, the more angry you are about the execution time of the keyboard. So let´s just connect the dots and increase the priority with the loudness of the keyboard Obviously future versions could check for words like "FSCKing slow machine" or "Faster, you son of an abacus" to increase the priority ....

Diese Storagedevices sind besser als herkömmlich: Leechi und Leechi Porn Edition, anaNAS Pro und natuerlich die die Speichergurke. Das ist Storage der Zukunft.

Many media outlets and Linux zealots talk the imminent death of Unix to the advantage of Linux. Nice to see, that customers think different. The Computerworld writes in "Survey: Unix has a long and healthy future, say users":

When asked to select a statement describing their Unix strategy, more than half underlined the importance of Unix by selecting "Unix is an essential platform for us and will remain so indefinitely" (42%) or "We are increasing our use of Unix" (15%). Another 18% described Unix's role as shrinking, but not disappearing. 17% pointed to plans to migrate away from Unix.

I have only a single problem with this article:

AIX was the most commonly reported flavor of Unix used by the survey base (42%), followed by Solaris/SPARC (39%), HP-UX (25%), Solaris/x86 (22%), Other Unix flavors/versions (19%), Mac OS X Server (12%) and OpenSolaris (10%).

I don´t think that AIX is the most comonly reported flavour, as they seperate the the Solaris franchise into three different groups. There should be at least 3% of people, that doesn´t use Solaris/SPARC but the other versions. Well, don´t believe a statistic without having brushed the data yourself

Maybe my perspective to the world is somewhat heliocentric, but this discussion is a good example how boneheaded even intelligent people can get. In the Linux mailing list there was a discussion about the integration of Xen into the kernel to ease up the development. After reading the discussion i hope that they won´t integrate it. The best solution Ingo Molnar can think of is ripping paravirtualisation out of Xen and make it a Linux only thing. This would effectively obliterate two advantages of Xen: The plattform independence and its independence from Hardware Support. With Xen it´s feasible to use even older hardware for virtualisation. Removing PVM from Xen would remove this capability.

Ingo suggests, that the hard virtualisation stuff should be done in hardware. It´s one of the strange things in IT, that many people believe that hardware virtualisation is superior to paravirtualisation. But this is not the case: HVM was introduced as a hack to run unmodified operating systems in a VM without doing run-time binary translation like VMware. Whenever you have modified drivers for your operating system your for the paravirtualized hardware it´s more efficient, especially when you leave the skewed benchmarks that just do compute-intensive load in a VM. All this hardware virtualisation stuff available now and in future is just done to do virtualisation with unmodified operating systems more efficient, but that shouln´t lead you the conclusion that this will be the most efficient way.

Even more disturbing was the comment of Theodore Tso:

What would be lost is dom0 support for other OS's, but really, is that
such a major loss? Linux has far better device driver support than Solaris or FreeBSD, so there is really that much gain in using some other OS for dom0?

Theodore may deserve a large heap of kudos for his work on filesystem, but his comment is really a little bit disconnected from Enterprise IT. The driver thing is a non-issue in server space. At the end all servers consists out of pretty much the same components. You find some Intel networking chips or the chipset-stuff from Nvidia. Decent harddisk controllers are from LSI or Adaptec. No sound cards, no scanners, no tv-cards. So there is not advantage in having more drivers for strange or old hardware in virtualisation.

But there are other things you should have: A fault management architecture, a fault anticipation architecture, thus a dying DIMM can´t take the whole server with it ... perhaps with running dozens of VM. Or a decent way to sparse-provision your virtual disks to reduce disk consumption. Both is missing in Linux and and both things are really important to do virtualisation besides of one or two VMs. Some people really should elevate their thinking about their desktops under their desks.

But at the end it´s just amusing: The media and the major proponents tell us at a regular schedule that the Linux developers are the brightest, biggest, most beautiful, most innovative community. But this community dances around the cow of Xen for years now and the integration hasn´t really done any significant step forward so far. In that time the communties around NetBSD and OpenSolaris integrated the stuff in their operating environments. So it can´t be really unintegrateable code or other technical problems as the processes and guidelines for coding are much more stringent in OpenSolaris. Perhaps it´s just NIH, as they have already an own virtualisation layer with KVM.

But at the end i won´t really complain about it: When Linux cripples their Xen implementation there are other operating systems that fill that gap. And one of them is Opensolaris.

I don´t know, if Chris Mellor was invited to a presentation of the S7000 storage series or what he did there (if he was invited) besides of drinking coffee, eating cookies and living in it´s own reality. Anyway ... if you need another reason to put him on the large heap of journalists of questionable quality, you should read his last article:

The Sun 7000 business model, with its commodity hardware aspects, is good news in Oracle-land, but its open source software is not. Not to Oracle, any way. Neither is the bag-of-bits aspect of the 7000's software environment particularly attractive to many customers. Here are the software lego blocks; now build the storage array hardware and software system yourself. No thank you. I want to have an easier time implementing my storage array.

Chris, the last time i´ve looked at the S7000 series, it was a appliance you order completely integrated with storage, software and server. Just like your beloved NetApp, Chris. Those systems are nothing much more than than storage, servers and software ...

There was a time, when an negative article at the Register could be an nail to the coffin of a product, now many articles are nails to the coffin of the Registers reputation.

Intel is rumoured to force HP away from Itanium by using their new half-centimetre process technology for their Tukwila. At least a photo published by a really trustworthy news site suggest such a move. So the next Superdome has ... well ... the size of a dome.

Hmm ... the Itanium franchise got another blow today: Intel announced today, that they delayed Tukwila. ETA now: First quarter of 2010. Their excuse:

During final system-level testing, we identified an opportunity to further enhance application scalability best optimized for high-end systems. This will result in a change to the Tukwila shipping schedule to Q1 2010.

Perhaps Intel should concentrate on their Xeon line and stop to develop a processor for HP

That doesn´t look really good. HP published their results for Q2 FY09: Enterprise Storage and Servers down 28% (ISS revenue down 29% Y/Y, BCS revenue down 29% Y/Y; Integrity revenue down 18% Y/Y, Storage revenue down 22% Y/Y; mid-range storage arrays (EVA) down 21%, ESS Blades revenue down 12% Y/Y), software revenue down 15% Y/Y, Desktops and Notebooks down 19%, Imaging and Printing 23% down.

There is an good example for the interesting nature of the SPECpower_ssj2008 benchmarks. Sun benchmarked three systems. A Sun Netra X4250 with 8 GB and with 32 GB.

• Unlike other loads there is only a small correlation of memory size and the number of ssj_ops. At 8 GB an Sun Netra X4250 yields 244,832 ssj_ops. The 32 GB version yields 251,555 ssj_ops
• There is an parameter that´s strongly correlated to the size of the memory. It´s the power consumption. The system with 8 GB consumes 226W. The one with 32GB needs 294W.
• Obviously this has large imact to the manager/journalist friendly single number as the result of the benchmark. The result is computed as the sum of ssj_ops at 10,20,30 and so on up to 100% utilisation divided by the used watts at each of this utilisations. When you have a way to reduce the power consumption by a large amount with only a small impact to performance, it´s a sure way to improve your SPECpower_ssj2008 result. As shown above the reduction of memory size is such a method. As you don´t have an large impact on performance by removing memory its quite easy to increase you benchmarketing number
• But there is more in you number: Look at the performance numbers: At 100% utilisation the system needs 226 watts. A system running at 0 percent utilisation needs 174 watts. This numbers are similar on every similar configured system A system doing nothing (okay, it runs the OS, another reason why we need tickless operating systems) needs 76% percent of the power consumption. So the obvious conclusion is: Run the system at 100% utilisation ... or at least try to get near to this number. But that isn´t so easy. You can run multiple application on a system to do so. But running multiple application need more memory. More memory than just the 8 GB used in this benchmark. So the benchmarks shows at best, that the small configurations are nonsense, at least when you have not an application that can load 2 procs and 8 cores with just 8 GB of memory.
• Another take away when you strive through this benchmarks that this benchmark is the return of single power supply configurations (the Sun configuration is one exception, all results are with doubled supplies. This is an important factor. At power supply is most efficient at high load. So benchmarkwise it´s best to load a single power supply as highest as possible. At a redundant load-sharing configuration a single power supply has a smaller load and runs at a lower efficency as the load is equally divided between the both. But for almost all jobs you have to use such a configuration as you want redundant power supplies for availability.

I really think that the SPECpower_ssj2008 needs some modification like mandating relevant memory sizes (and a load that really punishes small memory configurations) or forcing the vendors to use redundant configurations. Obviously the best way would be modification of all benchmarks (not only the ones from SPEC) to include the power consumption of the configurations. That would lead to reasonable and comparable configurations for power benchmarketing.

DISCLOSURE STATEMENT: Sun Netra X4250 server 600 overall ssj_ops/watt and (226 watts, 244832 ssj_ops) @ 100% target load, (210 watts, 121828 ssj_ops) @ 50% target load, (181 watts, 24150 ssj_ops) @ 10% target load, (174 watts) @ active idle target load. Sun Netra X4250 server 478 overall ssj_ops/watt and (294 watts, 251555 ssj_ops) @ 100% target load, (226 watts) @ active idle target load. Sun Netra X4250 server 437 overall ssj_ops/watt and (296 watts, 244832 ssj_ops) @ 100% target load, (225 watts) @ active idle target load. SPEC and the benchmark names SPECpower_ssj, SPECweb, SPECjbb, SPECjAppServer, SPEComp are trademarks of the Standard Performance Evaluation Corporation. Benchmark results stated above reflect results published on http://www.spec.org as of March 30, 2009. For the latest SPECpower_ssj2008 benchmark results, visit http://www.spec.org/power_ssj2008

Fujitsu disclosed some informations about an upcoming new processor. PC Watch reported about this event. This article written in Japanese (you can get an translation to English by Google ) is really interesting. They talked about their upcoming processor SPARC64 VIIIfx aka Venus: 8 cores extended by SIMD units yielding 128 GFLOPS. On this picture you see the effect of the move of 65nm to 45nm in regard of the used real estate for a core on the die. Fujitsu stated, that this proc is 2.5 times faster than Nehalem and has just a third of the power consumption. You have to take this with a grain of salt: As far as i understand the available information this CPU is a HPC CPU, not a real general purpose CPU. But it´s a SPARCv9

In ancient times (in IT world: 2005 or so) the Register was a good source of informations. You´ve got interesting hints to technology and a realistic view to IT, the major players and the newest hypes. Several years passed and now the Register is totally unreadable. I just keeping it in my feedreader as it´s important to me to be aware of Register articles before customers confront me with the nonsense written at the Register.

One of the names connected to the downfall of the Register (at least in my opinion) is Chris Mellor. Most of the time i ask myself about his connections to NetApp, but one of the best examples to give you an impression about the questionable quality of his articles is his recent output regarding about the Oracle 'faster, cheaper' with VMware. This article is so bug-infested, that i doubt, that Mr. Mellor did even basic research on this article.

I have a reader, who is really convinced that clusters are the solution for all problems of the world and that RAS is futile. In this arcticle i will talk about the "cluster for all problems". I just want to make a short comment here about such comments.

There is an important law in computing: Amdahls law mandates that the maximum performance of a highly parallel system is determined by the speed of the slowest component.

Now, just as a short information. The MPI latency of Myrinet is 2,6 microseconds, the MPI latency of Infiniband is 1.07 microseconds. 10GB Ethernet? In the range of 50 microseconds (although there are developments to reduce this). On the other side inside a really large non-clustered system: The memory latency of a Sun SPARC Enterprise M9000/64 is 437 nanoseconds to 532 nanoseconds.

And there we are in viewing distance of the problem why the idea of this reader that cluster is the solution of all problems is nonsense. As soon as you have to use the interconnect the process of transmitting the data becomes the slowest part in the equation. 1.07 microseconds are 1070 nanoseconds. At 1 GHz the length of one cycle is one nano seconds. At 3 GHz a third of a nanosecond. So you see ... in the latency of the interconnect you could do a lot of work. It´s really easy to see, that the connecting network is the slowest part in the equation.

When you look at the workloads for clusters, they are always corner cases. Rendering ... almost no communication between the nodes, the interconnect isn´t really a part of the processing. Many HPC tasks are similiar in nature or have at least a moderate amount of communication. Map-Reduce ... low amount of transported data as it´s a shared nothing distributed data architecture. But you can look at the problem like you want ... such architectures are cornercases. You don´t use Map/Reduce for SAP or Oracle Financials, only a few people render films.

I know that there are just clusters in the HPC Top 500 list. But that doesn´t mean that the people just use clusters for HPC. The point it: Linpack (the benchmark behind the list) is cluster-friendly. In my opinion it´s even too friendly to special purpose hardware with small memory footprint, but that´s a different discussion). Many problems in science aren´t problems you can compute on such a cluster. That´s the reason why there are a number large SMP/ccNUMA systems in HPC. They aren´t large enough to make it into the list, but on their workload the compute at least faster than most systems on the Top500 list.

Webserver Clusters are a great shared nothing architecture. Fileserver may be a great shared nothing architecture/no interconnect load as well with the advent of pNFS. But at the end ... corner cases.

It´s the same with Oracle RAC. Oracle RAC runs reasonably well on data sets where you can seperate the data access patterns (e.g. ZIP 1-10000 on first node, ZIP 10001 to 20000 and so on) but at a truly random pattern on the database it sucks, as it has to transport the cache quite often over the interconnect. By the way, is there nobody else out there who thinks it´s strange not to find a single Oracle result in the TPC-E benchmark ?

It´s not that Sun is the only computer company who thinks this way: IBM has its pSeries, HP has the Superdome ...

And there is my point: Blinded by the success of clusters in some areas some people (and this reader of my blog is one of them) believe that they will be an solution for all the inherent problems of cluster computing and cluster systems are the solution for all problems. .That´s simply not true. The world isn´t that simple like some people want to suggest. IT doesn´t consist only out webservers, rendering and Google-like computing. Everyone thinking otherwise should broaden it´s view on IT over the borders of his own problem sets.

Oracle changed their core multiplicators for software licensing. You can find the new version of their Oracle Processor Core Factor Table at the usual location.

They didn´t changed the multiplicators for SPARC CPU but the changes are nevertheless positive ones: A Power6 core has now a multiplicator of 1 instead of 0.75 like SPARC64 or UltraSPARC T2. This levels the playing field a little bit: In the past the Power6 could have a pricing advantage despite their incredible expensive cores (or what IBM calls a core) by the multiplicator for Oracle licensing. This advantage doesn´t exist any longer.

The second interesting change: The Itanium isn´t in the 0.75 range of high-end multicores ... it´s now in the x86 multicore group with a core factor of 0.5.