Intel TPC benchmarks show Linux as leader

prostoalex writes "Intel announced Linux to be the winner of Intel's own TPC-C benchmark test. A 32-processor Itanium machine performed 600,000 transactions per minute under Linux, leading the way before Windows as Unix. IBM's Unix server used to be the leader."

Comments

Link Is Broken

[MBCook]

The link is broken. Does anyone have a correct one?

Re:Link Is Broken

[Anonymous Coward]

News.com.com has a similar story a fews days back. What's strange is this one says Linux is nearly as good.

Re:Link Is Broken

[GiMP]

From news.com:
http://news.com.com/2100-1010_3-1013764 .html

Re:Link Is Broken

[ccevans]

What is says, if you read the link about the Windows record in the article, is that Linux with 32 older processors is nearly as good as Windows with 64 newer processors. If Linux can get nearly 600,000 with 32 processors, I would think it could add more than 102,000 if running on 64 processors.

Re:Link Is Broken

[Anonymous Coward]

Steal from your friends too? Or just ACs?

Wrong

[norwoodites]

It is a 64 Ia64 I2 running Windows that does about 606K transactions per minute which is a winner, a 32 IBM Power4 running AIX and DB2 (most likely with large pages, 128MB page size) gets about 600K so does the 32 IA62 running Linux. So it looks like windows suck in terms of transactions per minute.

order

[Stinson]

i think the writer of this confused the order of links...the part that says linux was the quickest on intels test, should point to the test, not intels main page...and why is that link (for the test announcement) put where it says unix used to be better.......someone should write an article on how to properly link articles. in short, don't make it confusing. [end rant]

Shocking

[jsse]

...leading the way before Windows as Unix. IBM's Unix server used to be the leader.

The link is broken, the typo is obvious, that can only be implying one thing...



Timothy, you need another cup of coffee. Quick.

Submitters need to read the article

[cookd]

The current record for TPC-C for non-clustered systems is a Windows Server 2003 (64 bit edition) on a 64 processor IA64 system from HP running SQL Server 2000 64 bit edition. It runs 707k TPM in official benchmarks.

The Intel system mentioned was a 32 processor IA64 system running Oracle. It got a score of "near 600k" in Intel's internal benchmarks.

Intel is keeping quiet about the details, and hasn't yet submitted a system for "official" testing. But it sounds like their kernel tweaks and their optimizing compiler have made a huge difference, and Oracle on Linux is a serious contender.

Re:Submitters need to read the article

[jsse]

You're right. The problem is in the wording of the headline:
A 32-processor Itanium machine performed 600,000 transactions per minute under Linux, leading the way before Windows as Unix.

I think he meant " leading the way next to Windows and Unix. It's rather confusing and should have been fixed before getting out of registered zone.

Also, in your post:
and Oracle on Linux is a serious contender.

Hmm...I might have to disgree with you on this. Linux(RedHat AS, or ES) works really closely with Oracle in the enterprise market. Big Tux are travalling worldwide to promote Redhat AS+Oracle Enterprise solution. I just attended a local conference held by Redhat+Oracle.

The solution is not cheap, though. The AS alone cost around US$6000 per (intel)processor, not including the cost of RAC (Oracle clusters). The stupid pricing might really kills much of the incentive adopting Linux+Oracle, especially when the customers realize that AS's High Availability and Oracle's cluster does not work well together. (straight out of my experience. That's why I said that's really stupid pricing - spending extra for something that can't work together)

Oh btw, fyi, if it's running on Redhat AS 2.1, it's using a 2.4 based kernel. AS would not support next version of kernel til next year.

Re:Submitters need to read the article

[f00zbll]

The parent post makes some good points, but other posts are seem to mis important differences. The windows system has a heavy client using COM+. The ibm system used BEA Tuxedo, which is server based queue. Using COM+ does not provide queue failover or replication. Using BEA Tuxedo on the other hand does provide clustering and fail over. Finding the right solution is what matters right, so using one technique over the over should be driven by the requirements. If your system has to handle that kind of load and not provide 100% failover, a COM+ solution is fine.

The question I keep asking myself is this. If your building a system that has to handle that kind of load, what's the likelihood 100% failover isn't a hard requirement? Obviously there are ways to make the system more manageable by sending high priority orders through a system that has real failover and send all low priority orders through one that isn't. Even with small trading systems, 100% is a hard requirement that is non-negotiable. Here's an excertp from HP's full disclosure.

The queuing mechanism used to defer the execution of the Delivery transaction must be disclosed.
The application creates a semaphore-based thread pool consisting of a user-specified number of threads, which open ODBC connections on the database. When a delivery transaction is posted, one of these threads makes the database call while the transactionâ(TM)s original thread returns control to the user. Upon completion, the delivery thread writes an entry in the delivery log and returns to the thread pool.

For those who don't read the full disclosure, the IBM system had an average response time of 120ms. The HP system running SQL Server averaged 320ms. That's more than twice as slow. All of that is fine if your requirements say it's ok right. Another important difference is the HP setup used 2GB routers, whereas the IBM system used 100MB routers. If you replace the routers in the HP setup with 100MB, it would probably would loose to the IBM setup.

Hm.

[Kickasso]

So the record is 707k TPM on 64 CPUs, but Linux scores ~600k TPM on 32 CPUs, right? This is impressive, but I wonder why Intel didn't use a 64 CPU system for its tests. Maybe Linux scales poorly beyond 32 CPUs?

Re:Hm.

[the eric conspiracy]

Maybe Linux scales poorly beyond 32 CPUs?

That certainly would be interesting since the scaling from 4 -> 32 CPUs was pretty much linear. The scaling past 32 CPUs would have to be really abysmal for the Linux machine to fail to exceed 707k TPM on a 64 CPU machine.

It is also very interesting to see that Intel got a lot of improvement from their own compiler rather than GCC.

it says no such thing

[kayen_telva]

wow, way to f!@# up a story timothy
actually a windows machine takes the lead
linux just happens to be getting very close

Re:it says no such thing

[molarmass192]

Actually, the Windows results in question used a 64 way box, the Linux test used a 32 way box. Linux hit 600K TPM on the 32 processor box, Windows hit 707 TPM on the 64 processor box. Comparing there results is about as useful as comparing a test of Windows on a P6 and Linux on a P2. This is best explained with a parody, "In other news tonight, tests show Windows runs very-fast on a P6 4Ghz but Linux was only pretty-fast on a P2 333Mhz. Therefore, Windows must be more performant than Linux.".

Wrong...

[burnsy]

IBM's Unix server used to be the leader.

Sorry, old news. MS/SQL Server used to be the leader (and still is). They lost the crown for about 3 weeks to IBM.

Opps.

[Anonymous Coward]

The author forgot to mention that IBM's own AIX gets +680,000 tmpC.

they used their own compiler in stead of gcc

[cyborch]

does this mean that intel's compiler will now be able to compile the linux kernel? and have they submitted their optimizations back to the kernel developer team (the article said that 20-30 percent performance improvement came from changes to linux itself)?

"Oh, _this_ is fair..."

[leonbrooks]

Yes, Windows gets 17% higher TPC-C... with twice as many processors. The word "Pyrrhic" immediately springs to mind.

What about Scalability?

[Dolemite_the_Wiz]

These results are all well and good (especially if they used an in-house compiler to bump the performance up) but what happens when this architecture scales?

IT Pros are not going to fall for the 'fastest' in the transaction processing department. Managers? That's another story.

IMO, If this server can't scale well Intel might as well market the results of this test as a 32 processor paper weight.

Dolemite
____________________