For almost the entire decade following Y2K, Sun Microsystems claimed the TPC-C benchmark was irrelevant, not representative of the modern data center and moreover, it cannot be used for sizing. Subsequently, Sun didn't publish any TPC-C results. This benchmark alienation came just after Sun claimed its final world record E10K TPC-C results with UltraSPARC-II processors and just before Sun introduced the UltraSPARC-III, circa 2001. These actions were not accidents nor is the recent Oracle+Sun's claim of a TPC-C result of 30,249,688 tpmC (see: http://blogs.sun.com/BestPerf/entry/20101202_sparc_t3_4_tpc).
The UltraSPARC-III had a blocking L1 cache, designed to optimize SPEC CPU95 benchmark execution. The UltraSPARC-III was late enough that the SPEC CPU95 was retired and replaced by SPEC CPU2000. SPEC CPU2000 had a larger footprint and a different execution pattern than its predecessor. Throughout the last decade, Sun's UltraSPARC processors were plagued by poor single processor industry-standard benchmark results. For Sun publishing any TPC-C results would be very embarrassing. (I know, as a member of Sun's benchmark council). When industry standard benchmark results were good Sun would publish them. When results turned out poor – the benchmark was attacked. When results became good ”again”, they are published, as was by Oracle+Sun on December 2, 2010.
While the TPC-C benchmark could be characterized by light-weight thread processing representing, “... the principal activities (transactions) of an order-entry environment. These transactions include entering and delivering orders, recording payments, checking the status of orders, and monitoring the level of stock at the warehouses” (see: http://www.tpc.org/tpcc/default.asp), this benchmark does provide a relative measure of the ability of a system to move data with processing capability secondary (The handful of SQL statements are rather trivial). Rapid data movement with low-quality processing is a forte of Sun's T1, T2, T3, and T4 processors. Interestingly, it was only after Oracle purchased Sun that TPC-C benchmarks on Sun SPARC were published again. It was known as far back as 2005 that the UltraT1 generated relatively good TPC-C results, but because the TPC-C benchmark was deemed worthless, Sun could not publish them less be called on the carpet for blatant duplicity. Oracle must think today's customers have no medium-term memory, a poor assumption for a database software company.
TPC-C results come in two flavors, single or clustered. A single result represents the capability of a single server with its storage. A clustered result approximates a cumulative sum of all the machines in the cluster. The larger the cluster, the better the result. Of course clustering like this has its mechanical and networking asymptotes, but generally you can pick a desired tpmC and then cluster servers and storage until that result is achieved. Sun made this argument a decade ago as a reason to avoid the TPC-C clustered results. In fact, Sun used to claim that IBM and others had to cluster their servers to get even publishable results.
Clustered TPC-C results can be used for certain comparisons. For example: The latest Sun+Oracle TPC-C result was achieved using a cluster of twenty-seven servers with 1726 SPARC processor cores. They then compared the results with the best IBM result which is a cluster of three, p780 servers with 192 POWER7 cores. Sun+Oracle has a 3X better result than IBM with 9X cores and 9X servers. The quotient is left as an exercise for the reader!
Regarding a heritage of duplicity, note the title of another blog on the same blogs.sun.com site that Oracle's latest TPC-C claim was made: http://blogs.sun.com/bmseer/entry/tpc_benchmarks_don_t_matter. What to believe is up to the imagination of the reader!