I’ve been wondering how much longer I’d have to wait for this to happen…
Back in 1998 I was a part of the team at Sequent Computer Systems that delivered the first non-clustered TPC-C result of 100,000 Tpm-C. Well, OK, I exaggerated, it was 93,901 but the prior Oracle record was held by HP with the V2200 (a Convex system actually) at 40,794 TpmC. Non-Clustered TPC-C results do not get doubled within a year’s time so it was quite the accomplishment at the time. Even more so given the detractors and skeptics at the time that couldn’t imagine a bunch of those “little Intel processors” churning out a record TPC-C result. Well, we did. It was a huge, expensive system with 64 processors, 64GB RAM, and hundreds upon hundreds of disk drives. The system cost for that big system was $131.67 per TpmC.
That was then, this is now. On June 8, Hewlett-Packard and Oracle joined to produce a 100,926 TpmC result with a single processor—a Xeon 5355 “Cloverdale”. While it has 4 cores, it is technically a single processor. So, they beat our 1998 number with 1/64th the number of CPUs and only 24GB memory as opposed to the 64GB we used. Interesting as well is that they used 100 disks in MSA-1000 enclosures. And the cost? Only $.78 per TpmC!
Mistaken Identity?
The benchmark was executed with Oracle Enterprise Linux, Standard Edition One and no ASM. I can’t find anything in the full disclosure report suggesting the datafiles were on raw partitions, but I’d be very surprised to find they used Ext3. Besides, there was no value assigned to filesystemio_options that would have enabled Direct I/O and I would be dollars to doughnuts that there was no filesystem caching overhead on a TPC-C run.
On the humorous side of things, you might get a chuckle to find that on page 10 of the Full Disclosure Report, the auditors missed the subtle distinction between Oracle Enterprise Linux and Red Hat Linux 4 as the following quote will attest:
Overview
This report documents the methodology and results of the TPC Benchmark C test conducted on the hp ProLiant ML350 G5. The operating system used for the benchmark was Red Hat Enterprise Linux 4. The DBMS used was Oracle Database 10g Standard Edition One.
This was a phenomenal result actually. I was quite glad to see it. I plan to share a couple other interesting things I noticed in the FDR as well in another blog entry.
Kevin Closson's Blog: Platforms, Databases and Storage 
Unbelievable how time flies!
I still remember reading the 1000 TPM-C result – also on Sequent in 1989, just before I left Oracle. We had just installed our Sequent – “hydra” was the node name in honour of the multiple 386 CPUs! – as the main MIS system at Oracle Australia.
At the time, everyone thought: “Wow! 1000 transactions per second, mainframes: eat your heart out!”
How wrong we were… 🙂
Of course, nowadays you’d do that with a desktop system!
Incredible how far this industry has come, eh?
Noons,
The 1,000 number was either a TPC-A or B, I can’t remember, but the C benchmark was still in the cooker at that time. Very early stuff….
Very early indeed. Version 6 OPS, IIRC.
But usable. Or at least: so said marketing!
🙂
Umm, there is a product called Red Hat Enterprise Linux.
Noons,
My “rememberer” fizzles here and in fact that TPC-A benchmark was before my time 1989. I’ll have to check, but the if I’m not mistaken it started with a 1000 TPC-A (tpsA) number and then later there was a clustered number with OPS. That would have been 7.0.12 OPS. The true feat at the time was processor scalability because “the big guys” were spending most of their time locking code instead of data to help prove Amdahl’s Law. Folks like Sequent and Pyramid were busy proving the law was moot… running commercial software at that.
Ceri,
Yes, golly, thanks for pointing that out. Red Hat Enterprise Linux does indeed exist. That is not the point here.
The point is that the benchmark is cited in the FDR and on the TPC website as having used Oracle Entperise Linux yet the abstract in the the FDR states the OS was Red Hat Enterprise Linux 4. They flubbed that up.
Noons,
OK, I dug out the old data. The 1989 results were 618 tpsA @ $11,006 $$/tpsA and then a clustered result of 1,002 tpsA @ $9,313 $$/tpsA. OK, enough of that trivial pursuit…
I see; your post makes it look like you were confused. Not to worry.
Those clever guys at Red Hat may have been able to finally match the TPC of those old Sequent boxes but they still haven’t been able to come up with a command line tool that visualizes how % busy each cpu is on a large-scale SMP server like we had on DYNIX/ptx. Ten years later and UNIX admins are still peering at vmstat!