Re: Linux betas NT in TPC testing, running Oracle8

r.e.ballard_at_usa.net wrote in message <7heu86$eq6$1_at_nnrp1.deja.com>...
>>
>> >I had some in the archives. I'll look them up.
>
>I went back and found a few - the www.silkwood.com archives, for one.

The URL you reference points to a Real Estate saleswoman by the name of Gwen Silkwood, I'm not sure this counts as valid professional benchmarking information :-) Perhaps you had another URL in mind.

>
>There have also been several tests between Apache/Linux and IIS/NT.
>
>> Try looking at:
>> http://www.zdnet.com/pcweek/stories/news/0,4153,401970,00.html
>>
>> This is a ZDNet comparison of NT, Netware,
>> Linux and Solaris on as near
>> as possible the same hardware.
>
>But not necessarily the same operating conditions. If default
>configurations are used, Linux would be running CGI (fork/exec) while
>NT runs in threads. A comparable test would be to use apache modules,
>which run fork but don't then exec.
>
Hmm, in a previous post you claimed that the seperate process fork/exec model of LINUX was vastly superior to the multi-threaded model of NT. Now when a benchmark actually put this to the test you want to claim that the NT machine had an advantage because it was using threads, looks like you want to have your cake and eat it.

>
>This would make sense. Solaris doesn't do write-behind, which means
>that updates to the directories, inodes, and allocation tables must be
>completed in real-time. A cached update takes about 200 microseconds,
>the physical update takes about 75 milliseconds. In the real world,
>Sun systems are usually set up with RAID drives that have as much as 16
>megabytes of cache. If the power fails, the RAID drive flushes cache
>immediately.

I'll assume by "RAID drive" you mean RAID controller, no drive has 16MB of cache. If so, that is far from standard on Sun systems.

>
>NT caches writes within the operating system. If there is a power
>failure that brings the NT down, the file-system may become corrupted.
>

Both Solaris and NT cache IO in the OS as does any modern operating system, caching on the RAID controller is a seperate matter entirely. On every NT RAID controller I've used (which is most of them) the cache on the controller can either:

1. Be configured as write-thru which is usually the default.
2. Be configured as write-back which should only be done if the system has a battery backup for the cache or is on a UPS.

You clearly don't have a good idea about the distinction between the filesystem cache of the operating system, the IO cache of the controller and the much smaller caches included on the drives (typically 1MB on high performance server drives, though IBM does have some drives with 4MB of cache each.)

>> You can always find a benchmark which will show your
>> particular platform in a good light.
>
>I think that was the original point of this thread.
>
>There are very few benchmarks that have the rigor of the TPC
>benchmarks, but when "informal" TPC benchmarks for Linux are
>announced, the publisher is threatened with a lawsuit.

Because the Transaction Processing Council, quite reasonably doesn't want it's benchmark value undermined by any Tom, Dick or Harry misusing it and bending the rules. You also have to pay TPC for the priviledge of using it's benchmarks. TPC has been very even handed about slapping the wrists of vendors who break the rules for disclosing/publishing benchmark results and has on numerous occasions forced the vendor to either withdraw or modify a result, LINUX is not being singled out for this treatment.

>
>Linux has been around, and has had SQL databases for nearly
>6 years now. In that time, nearly 10 TPB, TPC, and TPD benchmarks
>have been run and silenced. To this day, there are absolutely no
>publishable results.

Because those results have not met the rules of the benchmark and the people trying to publish them have not paid TPC for the right to use the benchmark. TPC/C is not a freely distributabe benchmark, it is tigthly controlled in order to ensure that all the results published meet the requirements of the benchmark. If TPC did not protect the benchmark in this way it would rapidly lose all credibility with the IT community at whom it is aimed.

>
>Linux and UNIX are very similar, and Linux actually benchmarks very
>well compared to other systems. Linux currently does NOT do well when
>using BOTH SMP (4 or more processors) AND hardware RAID. Essentially,
>disk writes eventually force the processors into a queue. Since the
>Linux kernel isn't allowed to "assume" that a write was successful,
>it will keep the buffer until the successful write is confirmed.

Hardware RAID controllers should not be an issue, if set in write-back mode they will report a succesful write as soon as the data reaches the cache on the controller.

>
>Linux/UNIX and NT are radically different programming environments.
>There are things one must do to get good performance out of NT that
>would be wasteful and inefficient on a Linux/UNIX system. Furthermore,
>Linux/UNIX programmers assume that their applications must be scalable
>and therefore do more integrity checking than NT programmers - who
>often assume that their process is the only one on the box.

Again apart from your personal prejudice what real data do you have to back up this wild generalisation.

>
>Assuming that Linux even comes close to the TPC numbers produced by SCO,
>Solaris 7, or other UNIX systems, and still provides the "no royalties"
>solution, it's likely that Linux will not set speed records, but WILL
>set "Bang for the Buck" records.
>

Again, you assume that the cost of the OS is a significant part of the overall cost of a valid TPC/C result. How many times do you have to be told that this is simply not true. If you want to actually verify this for yoursef I suggest you download a TPC/C full disclosure report from the TPC web site, at least then you'll have some idea of what you are talking about.

--
Nik Simpson
Server Product Manager
Intergraph Computer Systems