From owner-freebsd-stable@FreeBSD.ORG Tue Jun 28 16:30:02 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 C92E216A431 for ; Tue, 28 Jun 2005 16:30:02 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 395D243D5D for ; Tue, 28 Jun 2005 16:30:01 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: by nproxy.gmail.com with SMTP id g2so232087nfe for ; Tue, 28 Jun 2005 09:29:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eevZYrv7KIZHG0JAvYwIYtzxSM+pg3e+yWZChRDWoYmBYRYvz4CLAdN2XJr9VhdGiE1304GZTjL6wBOGpxupF08T5jGggpUq2cykTBjjptJmt+abnhl61gVSD/qBt8cor0ubAcQaQRD+i6poqjmBjtsaprlOgA3fNbNzPufj2i4= Received: by 10.48.249.6 with SMTP id w6mr156918nfh; Tue, 28 Jun 2005 09:29:59 -0700 (PDT) Received: by 10.48.244.20 with HTTP; Tue, 28 Jun 2005 09:29:59 -0700 (PDT) Message-ID: <1dbad31505062809292af0d294@mail.gmail.com> Date: Tue, 28 Jun 2005 18:29:59 +0200 From: Michael Schuh To: Paul Mather In-Reply-To: <1119973124.7900.20.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1dbad315050621051525f4c6fc@mail.gmail.com> <200506211451.j5LEpA2W024350@lurza.secnetix.de> <20050628092126.GB48140@isis.sigpipe.cz> <1119973124.7900.20.camel@zappa.Chelsea-Ct.Org> Cc: freebsd-stable@freebsd.org, Roman Neuhauser Subject: Re: FreeBSD MySQL still WAY slower than Linux X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Schuh 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 16:30:03 -0000 Yes, i know that and i agree with them. that was the reason, why my disk is tiled on first physical Gigabyte for Sw= ap, and the rest for the system.... my target was to compare 2 Versions not 2 Os-Types like FreeBSD and Linux, but FreeBSD and FreeBSD, in cases RELENG_4 with RELENG_5. so that the little difference between the different places for files, remember i install everytime at the beginning of second Gig on disk, should be flawlessy and not make the results so big, that the RELENG_4 has the double of speed from RELENG_5! best regards michael 2005/6/28, Paul Mather : > 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. >=20 > The point people are making is that location can have a significant > effect on performance, and so should not be dismissed out of hand. >=20 > 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): >=20 > 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. >=20 > Seek times: > Full stroke: 250 iter in 5.159189 sec =3D 20.637 msec > Half stroke: 250 iter in 4.206125 sec =3D 16.825 msec > Quarter stroke: 500 iter in 7.151951 sec =3D 14.304 msec > Short forward: 400 iter in 2.794380 sec =3D 6.986 msec > Short backward: 400 iter in 4.135579 sec =3D 10.339 msec > Seq outer: 2048 iter in 0.332711 sec =3D 0.162 msec > Seq inner: 2048 iter in 0.363152 sec =3D 0.177 msec > Transfer rates: > outside: 102400 kbytes in 7.677977 sec =3D 13337 kbyte= s/sec > middle: 102400 kbytes in 9.151475 sec =3D 11189 kbyte= s/sec > inside: 102400 kbytes in 14.345492 sec =3D 7138 kbyte= s/sec >=20 > 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? >=20 > Cheers, >=20 > Paul. > -- > e-mail: paul@gromit.dlib.vt.edu >=20 > "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 >