Re: Microsoft destroys TPC-C records!

Centuries ago, Nostradamus foresaw a time when Don Macpherson would say:
>"Raymond N Shwake" <rshwake_at_rsxtech.atww.org> wrote in message
>news:Fq5u8x.40J_at_rsxtech.atww.org...
>[snip]
>>
>> And of course, that means the customer has purchased *twelve*
>> licenses for Win 2000 Advanced Server, not to mention the associated
>> *client* licenses, and will have to maintain twelve servers.
>
>One of your implications is that of the supposed expense of the licences.
>The total of all of these is supposed to be included in the costed
>configuration, which calculates as approx 1/3 of the previous winner.
>Is that a problem?
>
>Saving $8 million dollars still sounds like a saving to senior management.

*Sounds like* is right. The costing associated with these benchmarks includes a sizable host of things including software licenses, hardware, and, I believe, service contracts.

As a result, licensing costs *are* controlled for in the calculations.

A valid conclusion would be that "ceteris paribus," even if there is an increase in licensing costs, if there is a greater decrease in hardware and service contract costs, this can still be a net savings.

>It looks like we may be about to see some price competition for the
>highend market.

That is less obvious. It assumes that the functionality is truly equivalent.

The benchmark may be little more than another iteration of the "Windows NT Scalability Day," where Microsoft showed off that if you have systems that are highly partitionable (e.g. - you can establish locality of reference for each transaction on one server) you can just bring in truckloads of rackmount servers and have them hum away generating "transactions."

Reality is that problems are not always that readily partitioned; at some point, you need intercommunications between the partitions. If there's a *lot* of such intercommunication, and it requires a *lot* of synchronization to keep things consistent, performance degrades dramatically.

This corresponds *directly* to the notions that: a) Communications between threads within a single process can be

   extremely cheap.
b) IPC between processes on the same host is fairly cheap. c) IPC between processes on different hosts requires some degree of

   synchronization across the network, and can be hundreds of times    slower than a) or b).

Apparently Microsoft was able to partition TPC/C into subproblems that largely involve local host IPC. In real world problems that require more communication between hosts, the cost goes up... --
:FATAL ERROR -- ERROR IN USER
cbbrowne@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html> Received on Tue Feb 22 2000 - 21:53:13 CST