Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel TPC benchmarks show Linux as leader

Posted by timothy on from the what-about-going-to-eleven dept.

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."

6 of 21 comments (clear)

  1. Re:Link Is Broken by Anonymous Coward · · Score: 1, Informative

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

  2. Re:Link Is Broken by GiMP · · Score: 4, Informative

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

  3. Submitters need to read the article by cookd · · Score: 5, Informative

    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.

    --
    Time flies like an arrow. Fruit flies like a banana.
    1. Re:Submitters need to read the article by jsse · · Score: 3, Informative

      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.

    2. Re:Submitters need to read the article by f00zbll · · Score: 2, Informative
      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.

  4. Wrong... by burnsy · · Score: 3, Informative
    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.