Date: Mon, 9 Jul 2001 15:12:21 -0700 (PDT) From: Lamont Granquist <lamont@scriptkiddie.org> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: Bert Driehuis <driehuis@playbeing.org>, "J.Goodleaf" <john@goodleaf.net>, <stable@FreeBSD.ORG> Subject: Re: Benchmarks from SysAdmin mag Message-ID: <20010709150950.L2131-100000@warez.scriptkiddie.org> In-Reply-To: <200107080407.f6847Ex16767@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
how about having a performance tuning application? don't make it part of the default install, so that you keep the install as easy to use for novice users as possible. but when it comes to tuning for benchmark testing have an application that goes through "do you want to turn on write caching on your IDE drives?" with a little explanation of what you're about to do... On Sat, 7 Jul 2001, Cy Schubert - ITSD Open Systems Group wrote: > 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 > > 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?20010709150950.L2131-100000>