From owner-freebsd-stable@FreeBSD.ORG Tue Jun 28 17:03:14 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE01B16A41C for ; Tue, 28 Jun 2005 17:03:14 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8615C43D53 for ; Tue, 28 Jun 2005 17:03:14 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j5SH3BWv048839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2005 13:03:13 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3) with ESMTP id j5SH35RQ008389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2005 13:03:06 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3/Submit) id j5SH354b008388; Tue, 28 Jun 2005 13:03:05 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Roman Neuhauser In-Reply-To: <20050628163928.GA51923@isis.sigpipe.cz> References: <1dbad315050621051525f4c6fc@mail.gmail.com> <200506211451.j5LEpA2W024350@lurza.secnetix.de> <20050628092126.GB48140@isis.sigpipe.cz> <1119973124.7900.20.camel@zappa.Chelsea-Ct.Org> <20050628163928.GA51923@isis.sigpipe.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 28 Jun 2005 13:03:04 -0400 Message-Id: <1119978184.7900.36.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org, Michael Schuh Subject: Re: FreeBSD MySQL still WAY slower than Linux X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2005 17:03:14 -0000 On Tue, 2005-06-28 at 18:39 +0200, Roman Neuhauser wrote: > # paul@gromit.dlib.vt.edu / 2005-06-28 11:38:44 -0400: > > Note how the transfer rate for the "outside" is almost twice that of the > > "inside." Suppose I run tests on two different operating systems, one > > of which resides in a partition on the "inside" portion and the other in > > one on the "outside" portion. > > Which is not the case according to the OP... > > > (Note that however good or bad it may be, the "location selection > > strategy in the driver" can only lay out data within the confines of > > the partition.) Now, I do a "dd" test and find that the "outside" OS > > is almost twice as fast as the other. Would it be wise to conclude > > that the slower OS is woefully inefficient compared to the faster one? > > Suppose both tests turn out to take roughly the same time. Should I > > conclude that the OS residing on the "inside" is just as efficient as > > the other OS? > > ... rendering this completely irrelevant. ...especially when you've cut out the context of my reply. :-) My apologies if it wasn't clear, but I was responding to your apparent assertion that location does not matter in disk performance benchmarks. If I had been responding to a specific aspect of the OP's benchmark (or indeed anything the OP has said), I'm sure I would have quoted that to make the context clear. > I have seen people come to a freebsd list with completely flawed > comparisons or benchmarks: OSs installed on different partitions > side by side, not taking VM cache into account, whatever, and be > told that their numbers are flawed. > > I have also seen people test a specific subsystem (dd), and be told > that their numbers don't reflect real world. > > And I have seen people test real world performance (install FreeBSD, > install MySQL, run a stress test, reformat, install Linux, install > MySQL, run a stress test) and get responses that try to make up > reasons why the bad results are the testers fault). Heck, if > installing an operating system, a database, and running it isn't > a real world test, I don't know what is. Even if the bug is "FreeBSD > puts /var/db/mysql in the wrong part of the disk" (then it's still > a problem in FreeBSD, not in the messenger). > > I just wish people here were less defensive, that's all. What you see as being defensive I see as being rigorous. If someone is making a claim based upon a performance benchmark, people will quiz the person conducting the benchmark to ascertain exactly how it has been undertaken. To put any stock in a benchmark result, it is important to be able to convince yourself it is a meaningful result. Well, at least most people I've encountered believe that to be the case. As it says in the BUGS section of the diskinfo man page: "There are in order of increasing severity: lies, damn lies, statistics, and computer benchmarks." ;-) Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa