From owner-freebsd-stable@FreeBSD.ORG Tue Jun 28 15:38:54 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 9759416A41C for ; Tue, 28 Jun 2005 15:38:54 +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 5FF4643D49 for ; Tue, 28 Jun 2005 15:38:54 +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 j5SFcp7m048551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2005 11:38:52 -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 j5SFcjKI008160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2005 11:38:45 -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 j5SFcivd008159; Tue, 28 Jun 2005 11:38:44 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Roman Neuhauser In-Reply-To: <20050628092126.GB48140@isis.sigpipe.cz> References: <1dbad315050621051525f4c6fc@mail.gmail.com> <200506211451.j5LEpA2W024350@lurza.secnetix.de> <20050628092126.GB48140@isis.sigpipe.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 28 Jun 2005 11:38:44 -0400 Message-Id: <1119973124.7900.20.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: Michael Schuh , freebsd-stable@freebsd.org 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 15:38:54 -0000 On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: > # olli@lurza.secnetix.de / 2005-06-21 16:51:10 +0200: > > For accurate measurements and comparisons, you have to make > > sure to use _exactly_ the same physical location on the > > disk. > > No you don't. You want to make a side-by-side comparison > of two products, and if one of them underperforms, it just > underperforms. You cannot use a poor location selection > strategy in the driver as an excuse for poor operation. The point people are making is that location can have a significant effect on performance, and so should not be dismissed out of hand. Here is what I get when I run diskinfo on one of the (somewhat elderly) disks I use in my desktop system (this is a drive I use for data, and it is idle): zappa# diskinfo -tv /dev/ad4 /dev/ad4 512 # sectorsize 25590620160 # mediasize in bytes (24G) 49981680 # mediasize in sectors 49585 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. Seek times: Full stroke: 250 iter in 5.159189 sec = 20.637 msec Half stroke: 250 iter in 4.206125 sec = 16.825 msec Quarter stroke: 500 iter in 7.151951 sec = 14.304 msec Short forward: 400 iter in 2.794380 sec = 6.986 msec Short backward: 400 iter in 4.135579 sec = 10.339 msec Seq outer: 2048 iter in 0.332711 sec = 0.162 msec Seq inner: 2048 iter in 0.363152 sec = 0.177 msec Transfer rates: outside: 102400 kbytes in 7.677977 sec = 13337 kbytes/sec middle: 102400 kbytes in 9.151475 sec = 11189 kbytes/sec inside: 102400 kbytes in 14.345492 sec = 7138 kbytes/sec 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. (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? 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