Date: Fri, 15 Jun 2001 08:32:04 -0400 From: Michael Sinz <msinz@wgate.com> To: tlambert2@mindspring.com Cc: rsi@panix.com, hackers@FreeBSD.ORG Subject: Re: Sysadmin article Message-ID: <3B2A0044.31D3FF3E@wgate.com> References: <200106150223.f5F2NLW08368@panix1.panix.com> <3B29CEF8.D6C525B@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > Rajappa Iyer wrote: > > > > http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm > > > > Any obvious reasons why FreeBSD performed so poorly for these people? > > Here is a repeat of my post to -advocacy: > > -- Terry > > ---- > > The article is meaningless. > > Too bad they titled it "Which OS is Fastest for High- > Performance Network Applications?" instead of "Which OS is > Fastest for MailEngine?". > > The only implied caveat is the statement "Our customers > frequently ask us which operating system is best for > running our software" in paragraph 3 of the "Background" > section. This should have been in bold type in the first > paragraph. > > -- > > It makes a number of very large blunders, which are really > inexcusable, given that it tries to represent itself as a > fair and unbiased comparison. Becareful before you state some of these - while I agree that the article and testing methods were not perfect, it is not what you think: > 2) Threaded processes are vastly inferior to > finite state automatons, when it comes to CPU > utilization on single CPU systems, and even on > multiple CPU systems, if there is async I/O > that can be scheduled on multiple CPUs. That is both a true-ism and a false-ism, depending on the way it is coded, the coder, and the architecture of the OS and hardware... > 3) FreeBSD turns of write caching on IDE drives, by > default, in FreeBSD 4.3 and above; you can set > it to be like Linux, Solaris, and Windows, if > you don't care about your data. On FreeBSD 4.2 > and below, Soft Updates are not enabled by > default. Either way, without tuning, you lose. And if you read the article, you may find the following text: We installed all operating systems on identical 4-GB SCSI-3 drives (IBM model DCAS-34330), and ran the tests on the same machine (ASUS P3B motherboard, Intel Pentium III 550-MHz processor, 384-MB SDRAM, Adaptec 2940UW SCSI controller, ATI Rage Pro 3D video card, Intel EtherExpress Pro 10/100 Ethernet card). So, IDE drive issue (they just suck) is not an issue here. Yes, IDE has problems, but if they did not use it, don't claim that it was an issue. > 4) IDE drives do not support tagged command queueing, > except IBM DTLA drives, which are known to fail > due to overheating and due to their electronics > being too slow for their radial track density for > interior tracks. Again, don't claim it as a problem when they specifically stated that SCSI was used and which specific SCSI drive and hardware setup. > 5) Real servers with storage and I/O requirements > use SCSI drives so they can benefit from tagged > command queues, which allow I/O to be interleaved > instead of serialized. I agree. And, it seems, so did the testers. [...] > 13) For each connection, there is a tcptmpl structure, > which is used for keepalives. This structure will > consume one mbuf per connection; in addition, the > average TCP window size will be 16k; so you will > need 16k/2k (8) mbufs for custer pointers plus > 16k/256 (64) mbufs for the window data, plus one > mbuf per connection, pplus one mbuf per connection, > if you are setting options. This means that you > will potentially need 74 mbufs per connection you > intend to support; without patching, this also is > not tunable except at compile time, and the value > was not tuned. Is this not a potential issue with the OS? > 14) The "average througput per network architecture" is > extremely misleading, both because of the limited > and inefficient architectures used in the test, and > in using an average to "determine" which was "the > best architecture for use on all OSs". Per OS numbers > would have been much more meaningful, since the final > architecture was chosen based on the average, and not > based on what was best for the OS being tested. I fully agree. That part of the test/description was completely wrong just because it assumed too many things and did not give a reasonable example of each implementation (and how each did on each OS). It is obvious that in the current stable FreeBSD that anything that is heavily threaded will not do as well as on other operating systems that have better threading support. But this can also be seen as a reasonable complaint against FreeBSD. And we know that and the next major FreeBSD release will have addressed it. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B2A0044.31D3FF3E>