| Author |
Maximum Speeds for SATA Drives
|
|
|
| When a SATA drive employs more than one cylinder, are they striping data
across the cylinders transparently, or are they just laying out data
contiguously on any given track / cylinder? I have someone telling me
that they have been measuring 150 MB / second throughputs on individual SATA
drives, which is way beyond what a 7200 rpm rotation speed on an individual
track should be able to give you. I think they are probably measuring a
transfer speed out of a cache and don't realize it.
I've seen various consumer SATA RAID arrays record write throughputs around
30 to 60 MB/second, which implies that the individual drives rarely deliver
more than 15 MB / second, and that would be for contiguous data.
What kinds of performance numbers have others seen for individual SATA
drives where the data is fragmented?
Any insights on performance of individual SATA drives is appreciated.
--
Will
| |
| Thor Lancelot Simon 2007-07-31, 1:13 am |
| In article < mfSdnbQdI_64ODPbnZ2dnUVZ_gGdnZ2d@giganew
s.com>,
Will <westes-usc@noemail.nospam> wrote:
>
>I've seen various consumer SATA RAID arrays record write throughputs around
>30 to 60 MB/second, which implies that the individual drives rarely deliver
>more than 15 MB / second, and that would be for contiguous data.
I suppose if you're uninterested in the facts it implies that. A trivial
test will determine that for contiguous data even the cheapest modern
SATA drives write at about three to four times the rate you quote.
Look elsewhere for the explanation for poor long write performance with
SATA RAID arrays. It's not the write rate of the underlying drives
that's the problem.
--
Thor Lancelot Simon tls@rek.tjls.com
"The inconsistency is startling, though admittedly, if consistency is to
be abandoned or transcended, there is no problem." - Noam Chomsky
| |
|
| "Thor Lancelot Simon" <tls@panix.com> wrote in message
news:f8m8t7$9ou$1@reader2.panix.com...
> In article < mfSdnbQdI_64ODPbnZ2dnUVZ_gGdnZ2d@giganew
s.com>,
> Will <westes-usc@noemail.nospam> wrote:
>
> I suppose if you're uninterested in the facts it implies that. A trivial
> test will determine that for contiguous data even the cheapest modern
> SATA drives write at about three to four times the rate you quote.
How are they doing this? They are striping data across four or more
platters?
--
Will
| |
| Maxim S. Shatskih 2007-07-31, 1:13 am |
| > I've seen various consumer SATA RAID arrays record write throughputs around
> 30 to 60 MB/second, which implies that the individual drives rarely deliver
> more than 15 MB / second, and that would be for contiguous data.
70MB/s is OK for more-or-less modern SATA drive. The run seems to be long
enough to not be influenced by the cache.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
| |
| Anton Rang 2007-07-31, 1:14 pm |
| "Will" <westes-usc@noemail.nospam> writes:
>
> How are they doing this? They are striping data across four or more
> platters?
No.
They are using higher densities than you seem to be assuming.
| |
|
| "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:f8mjje$2e62$1@news.mtu.ru...
around[vbcol=seagreen]
deliver[vbcol=seagreen]
>
> 70MB/s is OK for more-or-less modern SATA drive. The run seems to be long
> enough to not be influenced by the cache.
Wow, amazing. What is the easiest way to setup a test to show that
performance level on a single drive?
--
Will
| |
| Rob Turk 2007-07-31, 1:14 pm |
| "Will" <westes-usc@noemail.nospam> wrote in message
news:kcKdndE06pXb7DLbnZ2dnUVZ_sGvnZ2d@gi
ganews.com...
>
> Wow, amazing. What is the easiest way to setup a test to show that
> performance level on a single drive?
>
> --
> Will
Boot a stand-alone Linux CD that supports your SATA adapter and then run a
large 'dd' directly from the raw drive device. Something like:
# time `dd if=/dev/hda of=/dev/null bs=32k count=1000000`
Rob
| |
| Maxim S. Shatskih 2007-07-31, 7:14 pm |
| > Boot a stand-alone Linux CD that supports your SATA adapter and then run a
> large 'dd' directly from the raw drive device. Something like:
> # time `dd if=/dev/hda of=/dev/null bs=32k count=1000000`
Playing with "bs" is also a good idea. (S)ATA protocol has a natural block size
of 64K.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
| |
|
| "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:f8o0d0$2mfl$1@news.mtu.ru...
>
> Playing with "bs" is also a good idea. (S)ATA protocol has a natural block
> size
> of 64K.
So if you were going to be copying large files to a single SATA device,
would using a Windows "Allocation Unit" of 64K when formatting the drive
make any sense?
On SATA drives I've generally seen the throughput maximize when I make
Windows allocation units 8K, and performance degrades a bit at 16K and 32K.
I haven't tried 64K.
--
Will
| |
| Bill Todd 2007-08-01, 1:13 pm |
| Will wrote:
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:f8o0d0$2mfl$1@news.mtu.ru...
>
> So if you were going to be copying large files to a single SATA device,
> would using a Windows "Allocation Unit" of 64K when formatting the drive
> make any sense?
>
> On SATA drives I've generally seen the throughput maximize when I make
> Windows allocation units 8K, and performance degrades a bit at 16K and 32K.
> I haven't tried 64K.
Any reasonably-competent Copy function will preallocate the entire
output file prior to initiating the data copying, so the allocation unit
size should be irrelevant (unless the free space on the disk is severely
fragmented).
- bill
|
|
|
|