Date: Sat, 21 Jul 2007 16:47:14 -0500 From: Tim Daneliuk <tundra@tundraware.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: SATA 300 Drive Being Run At 150 Message-ID: <46A27EE2.8060204@tundraware.com> In-Reply-To: <20070721165539.GA2579@dan.emsphone.com> References: <46A22253.8080100@tundraware.com> <20070721165539.GA2579@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <Intel ICH7 SATA300 controller> 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 <WDC WD2500JS-00NCB1 10.02E02> at ata2-master SATA150 >> ^^^^^^^ >> Using dd, I have confirmed that the drive is running nowhere near >> SATA-III speeds, at least on reads: >> >> 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. 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. Thanks for your time ... -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A27EE2.8060204>