Date: Sat, 07 Jul 2001 21:06:17 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Bert Driehuis <driehuis@playbeing.org> Cc: "J.Goodleaf" <john@goodleaf.net>, stable@FreeBSD.ORG Subject: Re: Benchmarks from SysAdmin mag Message-ID: <200107080407.f6847Ex16767@cwsys.cwsent.com> In-Reply-To: Your message of "Sun, 08 Jul 2001 03:29:32 %2B0200." <Pine.BSI.4.21.0107080307250.29990-100000@c1111.nl.compuware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSI.4.21.0107080307250.29990-100000@c1111.nl.compuware. com>, B ert Driehuis writes: > On Sun, 8 Jul 2001, J.Goodleaf wrote: > > > I lack the technical expertise to judge this article fully. Any thoughts? > > FreeBSD comes out at the bottom, _below_ Win2K. > > > > http://www.samag.com/articles/2001/0107/0107a/0107a.htm > > >From the article: > > "If disk I/O occupies a significant run-time portion of your > application, your disk I/O tasks will run up to 10x faster on Linux and > Windows 2000, when compared to Solaris, or 6x faster than FreeBSD." > > Knowing that e-mail is the app under measurement, it is worth pointing > out that the article mentions that file systems make a hell of a > difference, but is silent about tweaking the file system, and why some > filesystems are slower than others. > > If you don't enable softupdates on FreeBSD, mail delivery takes a > significant hit. Conversely, Linux's EXT2 file system may be fast, but > it is not robust with respect to file system integrity, so running a > heavily loaded mail server will result in loss of mail if the server > crashes. > > The article doesn't mention if they checked the disk was properly > configured either. If SCSI tagging is not used, performance will suffer > too. Etcetera, etcetera. > > Maybe the authors have done some homework in this area, but if they did, > the article doesn't show it. I hate these quicky consumer tests. I > remember, too vididly, that a Dutch consumer rag once concluded that a > Mac was an order of magnitude slower than a contemporary PC because MS > Word ran slow on it. Turned out they ran Windows under VirtualPC on > that Mac... ... To add to what you've just said, Magazines like to play games, especially those little games that compare apples and oranges. It was DES who two years ago wrote on this list (I'm quoting from memory), "what you read in the media is true, until it's something you know about." What's my point? Marketing. Yes, marketing. 1. Softupdates has been around for a while. Many of us, including myself, use softupdates on critical production systems on a daily basis, AND on root filesystems. Should not softupdates be the default? If not the default, at least an option in sysinstall? 2. Write caching can under the right set of circumstances have a detrimental affect on RAS (Reliability, Availability, and Serviceability). That's why IDE write caching is turned off by default. Those of us who have been following the write caching arguments on this list over the past 12 months or so, have learned how to turn off write caching on SCSI drives as well. However, turning off write back cache (enabling write through cache) does have a detrimental affect on performance. I think that for marketing purposes, e.g. magazines writing articles that compare filesystem performance, a sysinstall option to enable filesystem performance -- turn on write caching -- at the expense of RAS -- and make it abundantly clear to the user that their data is at risk -- might go a long way to reducing bad press when filesystems are compared. Once again before people forget (we have short memories) let me stress that a sysinstall option to turn on write back cache should have strong words discouraging selection of the option but should also outline the performance benefit. Of course this allows the average uneducated end-user to shoot themselves in the foot, and lord knows we've had enough discussions about this concept on the various FreeBSD mailing lists over the years. For those of us technically adept enough to successfully buildworld, this is just fluff, as enabling softupdates and disabling/enabling write back cache on IDE (via loader) and SCSI (via camcontrol) drives is trivial and hardly worth discussion. However when it comes to the media and the masses, perception is reality (even though we know better). In short our choice is, do we want to give the user yet another option with its benefits and pitfalls or do we want to coddle the end user to protect them from themselves? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107080407.f6847Ex16767>