SATA 300 Drive Being Run At 150

[Erik Trulsson]

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
ertr1013 at student.uu.se