From owner-freebsd-questions@FreeBSD.ORG Sat Jul 21 22:11:39 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E900416A418 for ; Sat, 21 Jul 2007 22:11:39 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7267B13C465 for ; Sat, 21 Jul 2007 22:11:39 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:54103 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with smtp (Exim 4.66) (envelope-from ) id 1ICNAo-00076o-6o for freebsd-questions@freebsd.org; Sun, 22 Jul 2007 00:11:38 +0200 Received: (qmail 6437 invoked from network); 22 Jul 2007 00:11:33 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 22 Jul 2007 00:11:33 +0200 Received: (qmail 84510 invoked by uid 1001); 22 Jul 2007 00:11:33 +0200 Date: Sun, 22 Jul 2007 00:11:33 +0200 From: Erik Trulsson To: Tim Daneliuk Message-ID: <20070721221133.GA84324@owl.midgard.homeip.net> Mail-Followup-To: Tim Daneliuk , Dan Nelson , FreeBSD Mailing List References: <46A22253.8080100@tundraware.com> <20070721165539.GA2579@dan.emsphone.com> <46A27EE2.8060204@tundraware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A27EE2.8060204@tundraware.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Originating-IP: 83.253.10.135 X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1ICNAo-00076o-6o. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1ICNAo-00076o-6o 94131d83fd8fc9c452063bda0a535f26 Cc: Dan Nelson , FreeBSD Mailing List Subject: Re: SATA 300 Drive Being Run At 150 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2007 22:11:40 -0000 On Sat, Jul 21, 2007 at 04:47:14PM -0500, Tim Daneliuk wrote: > Dan Nelson wrote: > >In the last episode (Jul 21), Tim Daneliuk said: > >>I asked this question a while back, but needed to do more digging to make > >>sure I had latest sources etc. > >> > >>I have an Intel motherboard that shows this for a SATA controller: > >> > >>atapci1: port > >>0x20c8-0x20cf,0x20ec-0x20ef,0x20c0-0x20c7,0x20e8-0x20eb,0x20a0-0x20af mem > >>0x90204000-0x902043ff irq 19 at device 31.2 on pci0 > >> > >>But the hard drive - a SATA 300 device - shows up like this: > >> > >>ad4: 238475MB at ata2-master SATA150 > >> ^^^^^^^ > >>Using dd, I have confirmed that the drive is running nowhere near > >>SATA-III speeds, at least on reads: "SATA-III" ? There is no such thing as far as I know. I guess you mean SATA300 > >> > >>968470075 bytes transferred in 7.132891 secs (135775249 bytes/sec) > > > >What was your dd commandline? If you've got more than 1GB of RAM and > >tested by reading a file and not the raw device itself, you just tested > >FreeBSD buffer cache. > > I just did: > > dd if=abigfile of=/dev/null > > But, you're right, cacheing does make things look better, so I did this: > > dd if=/dev/ad4s1 of=/dev/null count=100000 > 100000+0 records in > 100000+0 records out > 51200000 bytes transferred in 9.569672 secs (5350236 bytes/sec) > > > Hmmm ... that seems slow, then again, 512b is a silly block size. > How about: > > dd if=/dev/ad4s1 of=/dev/null count=100000 bs=1024 > 100000+0 records in > 100000+0 records out > 102400000 bytes transferred in 9.916191 secs (10326546 bytes/sec) > > Better, but really, the block size should be even bigger in today's reality: > > dd if=/dev/ad4s1 of=/dev/null count=100000 bs=4096 > 100000+0 records in > 100000+0 records out > 409600000 bytes transferred in 13.556418 secs (30214471 bytes/sec) > > So, going for broke: > > dd if=/dev/ad4s1 of=/dev/null count=10000 bs=32768 > 10000+0 records in > 10000+0 records out > 327680000 bytes transferred in 5.051286 secs (64870609 bytes/sec) > > (I got similar results for 16K blocks, so this would appear to > be the max for this combination of drive/controller/OS overhead.) > > Not bad, and in line with your observation below about the max > sustained speed of the drive's buffer to disk. Yes, 65MB/s sounds about right for that disk. Most "mainstream" disks today max out at about that speed. > > According to > >http://www.wdc.com/en/products/productspecs.asp?driveid=135 , that > >drive's maximum sustained speed is only 93.5 MB/sec, so it doesn't > > It's actually less than that, since there is some overhead needed for > serial transfer beyond just the 8 bits of data. The max speed is probably > more like 75 MB/sec. > > >really matter if your interface is running at SATA150 or SATA300 unless > >you plan on reading exclusively from its 8MB buffer :) > > > > Point taken - and I never expected to see a full 300MB/sec throughput. > But ... I *am* curious why the interfaces are not running at full speed, > since both drive and controller are SATA-300 devices. > > The theory of the moment is thus that the drive cable can't handle SATA-300. > We'll see. Another possibility is that the drive has been jumpered to only run at SATA150 speed for maximum compatibility with old chipsets. See http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=1337 for more information on this. -- Erik Trulsson ertr1013@student.uu.se