Maybe this is why IBM won't do a TPC benchmark using IDS...
You can read the full article here: http://www.theregister.co.uk/2009/09/29/tpc_slaps_oracle/ But what was interesting was the following quote: "Big Blue, for one, seems to have mastered the black art of de-randomizing the data coming out of the TPC-C transactions, steering data to precise bits of system cache on Power Systems boxes running AIX and DB2 - or so other server makers have claimed to me. This tuning may account for nearly half of the performance of the box. I base this assertion on IBM's own Commercial Processing Workload (CPW) benchmarks for the i/OS-Power platform, which are loosely based on the TPC-C test, and its similar Relative Performance (rPerf) test for its AIX-Power platform, which is also derived from the TPC-C test. Several years ago, the OLTP performance of Power servers started to diverge, with AIX machines suddenly able to perform around 50 per cent more OLTP work than their i/OS counterparts. I have attempted to get clarification on this divergence from Big Blue's benchmarkers, to no avail, for many years." Kind of says it all. I guess it would take too much time and money to figure out how to game the system using IDS. Maybe Jerry K. is just to honest to want to stoop to Oracle and of course DB2's willingness to cheat. I mean when you have an inferior product, you have to, just to keep up. But hey! What do I know? ;-) -G _________________________________________________________________ Bing™ brings you maps, menus, and reviews organized in one place. Try it now. http://www.bing.com/search?q=restaurants&form=MLOGEN&publ=WLHMTAG&crea=TEXT_MLOGEN_Core_tagline_local_1x1
Ian Michael Gumby wrote: > You can read the full article here: > http://www.theregister.co.uk/2009/09/29/tpc_slaps_oracle/ > > But what was interesting was the following quote: > "Big Blue, for one, seems to have mastered the black art of > de-randomizing the data coming out of the TPC-C transactions, steering > data to precise bits of system cache on Power Systems boxes running AIX > and DB2 - or so other server makers have claimed to me. This tuning may > account for nearly half of the performance of the box. I base this > assertion on IBM's own Commercial Processing Workload (CPW) benchmarks > for the i/OS-Power platform, which are loosely based on the TPC-C test, > and its similar Relative Performance (rPerf) test for its AIX-Power > platform, which is also derived from the TPC-C test. Several years ago, > the OLTP performance of Power servers started to diverge, with AIX > machines suddenly able to perform around 50 per cent more OLTP work than > their i/OS counterparts. I have attempted to get clarification on this > divergence from Big Blue's benchmarkers, to no avail, for many years." > > Kind of says it all. > > I guess it would take too much time and money to figure out how to game > the system using IDS. > Maybe Jerry K. is just to honest to want to stoop to Oracle and of > course DB2's willingness to cheat. > I mean when you have an inferior product, you have to, just to keep up. > > > But hey! What do I know? ;-) Even less than teh author of this article. Let's do this in sequence: 1. IBM filed the complained before that second announcement from Oracle, so it's no wonder that the complain didn't address that one. 2. TPC-C is very easily partitionable by "warehouse id". DB2 hit 440k tpmc on a cluster for the win2k launch nearly ten years ago, so it's not exactly an art to keep CPU caches hot. 3. CPW is loosely related to TPC-C.. OK so are apples to oranges. That entire line of reasoning is completely built on thin air. 4. There is no doubt that benchmark specials are employed by all vendors. Whether that's some really support contracts or odd choices of system settings. Alas, the full disclosure of TPC-C allows customers to find those. 5. Let's not forget that Oracle and DB2 has a few results that were very comparable when the benchmark hovered around 700k. DB2 was not 50% faster than Oracle (although it was faster). So if IBM had mastered something magic then it must have shared it with Oracle.... 6. The bummer about this ad was that when you cite TPC-C you must allow the customer to KNOW whether apples and Oranges are compared. That is number of core, memory, price... The fact that Oracle doesn't spit out the number is the smaller problem. Anyone with a semi scalable system can produce any TPC-C number. The question is at which expense of hardware and software. But hey what does Michael know....it's not that he has ever published a TPC-C benchmark... -- Serge Rielau SQL Architect DB2 for LUW IBM Toronto Lab
Serge, Clearly you can't think before you write. I was merely relaying what the author wrote. Its not what I *know* because frankly, I *know* more than I am freely allowed to admit to knowing and if you knew what I know, some of my postings would make more sense. ;-) But lets forget about me. Its about what the author wrote and who's going to read it. Sure its a slap against Oracle for pre-announcing something that hasn't been verified. I'm sure Oracle would take that 10K fine as part of the cost of doing business. Frankly their announcement was more to highlight their commitment to keeping Sun around more than it was to slap IBM across their face with a gauntlet and declare a database war. So Oracle's ad was/is a success from that standpoint. But it was interesting on how the author, in the spirit of fair play, talked about how IBM was gaming the system. To the author's point, the results of DB2 on AIX are much better than the results of DB2 on I series. So one has to wonder if DB2 is truly DB2 on all relative platforms, why the big difference in numbers? So rather than get hot at me, why don't you send a letter to the author. And no, I haven't run any TPC benchmarks. I was busy cleaning up the mess your bud Bob P. made when DB2 8.0 was released, among other things. ;-) But I digress. The point I was making was that Oracle has tossed down a gauntlet and is declaring war on IBM. IBM has two war horses in their stable, but it seems they can only fight with one horse. TPC doesn't sell product, but it can cost you the sale. Its a talking point and sometimes the fact that there are no numbers is worse than having numbers. ;-) But hey, what do I know? Maybe its more about the sales process and cycle, and what makes a customer buy a product. After all, some of us were cross matrix'd between S&D and the Lab. ;-) -G > From: srielau@ca.ibm.com > Subject: Re: Maybe this is why IBM won't do a TPC benchmark using IDS... > Date: Tue, 29 Sep 2009 23:23:59 -0400 > To: informix-list@iiug.org > > Ian Michael Gumby wrote: > > You can read the full article here: > > http://www.theregister.co.uk/2009/09/29/tpc_slaps_oracle/ > > > > But what was interesting was the following quote: > > "Big Blue, for one, seems to have mastered the black art of > > de-randomizing the data coming out of the TPC-C transactions, steering > > data to precise bits of system cache on Power Systems boxes running AIX > > and DB2 - or so other server makers have claimed to me. This tuning may > > account for nearly half of the performance of the box. I base this > > assertion on IBM's own Commercial Processing Workload (CPW) benchmarks > > for the i/OS-Power platform, which are loosely based on the TPC-C test, > > and its similar Relative Performance (rPerf) test for its AIX-Power > > platform, which is also derived from the TPC-C test. Several years ago, > > the OLTP performance of Power servers started to diverge, with AIX > > machines suddenly able to perform around 50 per cent more OLTP work than > > their i/OS counterparts. I have attempted to get clarification on this > > divergence from Big Blue's benchmarkers, to no avail, for many years." > > > > Kind of says it all. > > > > I guess it would take too much time and money to figure out how to game > > the system using IDS. > > Maybe Jerry K. is just to honest to want to stoop to Oracle and of > > course DB2's willingness to cheat. > > I mean when you have an inferior product, you have to, just to keep up. > > > > > > But hey! What do I know? ;-) > Even less than teh author of this article. > Let's do this in sequence: > 1. IBM filed the complained before that second announcement from Oracle, > so it's no wonder that the complain didn't address that one. > 2. TPC-C is very easily partitionable by "warehouse id". > DB2 hit 440k tpmc on a cluster for the win2k launch nearly ten years > ago, so it's not exactly an art to keep CPU caches hot. > 3. CPW is loosely related to TPC-C.. OK so are apples to oranges. > That entire line of reasoning is completely built on thin air. > 4. There is no doubt that benchmark specials are employed by > all vendors. Whether that's some really support contracts > or odd choices of system settings. > Alas, the full disclosure of TPC-C allows customers to find those. > 5. Let's not forget that Oracle and DB2 has a few results that > were very comparable when the benchmark hovered around 700k. > DB2 was not 50% faster than Oracle (although it was faster). > So if IBM had mastered something magic then it must have shared it > with Oracle.... > 6. The bummer about this ad was that when you cite TPC-C you must allow > the customer to KNOW whether apples and Oranges are compared. > That is number of core, memory, price... > The fact that Oracle doesn't spit out the number is the smaller > problem. Anyone with a semi scalable system can produce any TPC-C > number. The question is at which expense of hardware and software. > > But hey what does Michael know....it's not that he has ever published a > TPC-C benchmark... > > -- > Serge Rielau > SQL Architect DB2 for LUW > IBM Toronto Lab > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list _________________________________________________________________ Microsoft brings you a new way to search the web. Try Bing™ now http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try bing_1x1