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: <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:
"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. -- <Insert your favourite quote here.> Erik Trulsson [EMAIL PROTECTED] _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
