Skip site navigation (1)Skip section navigation (2)
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>