Re: [gentoo-user] Normal disk speed?

[Florian Philipp]

Am 02.10.2010 14:44, schrieb Florian Philipp:
> Am 02.10.2010 14:11, schrieb Volker Armin Hemmann:
>> On Saturday 02 October 2010, Florian Philipp wrote:
> [...]
>>>
>>> Assumptions:
>>>
>>> 1. Seek time is constant. For HDDs we can take an average value. Of
>>> course this doesn't work for tapes. They have a seek time which
>>> increases linearly with the distance between the fragments.
>>
>> I think you misunderstood my remark.
>>
>> Tapes try to stream. Take an old DLT drive with 5-10mb/sec streaming speed.
>> Slow, isn't it?
>>
>> But when you do a backup on such an old tape even with a modern harddisk you
>> have problems keeping it streaming. As soon as you hit a directory with many
>> small files - like ~/Mail or /usr/portage you are screwed.
>>
>> Yes, you have wonderfull 100mb/sec when you read a big, fat file. Or a single
>> small file. But when you have houndreds, thousands or hundreds of thousands of
>> small files, harddisks suck.
>> And your tape drive has to stop and rewind every couple of seconds because
>> your harddisks were not able to keep up the required 10mb/sec. Trueley
>> pathetic.
>
> Well, that's exactly what my little math shows. When you read 4kB files,
> you can end up with 0.0065 * 50 MB/s = 0.32 MB/s effective throughput
> (worst case).
>
>>
>> Besides, seek times are not constant ;)
>>
>
> Sure they aren't. That's why it is stated as an assumption. It is just a
> model.  Like every model it has its limits.[1] It doesn't take into
> account prefetching, caching and NCQ/TCQ, for example.
>
> Still it is a valid assumption: *On average*, the read/write head has to
> move around half the radius of the platter to reach its next position
> and it has to wait for half a rotation until the right block is under
> the head. If we assume that fragments are uniformly distributed over the
> whole disk, we can simply take an average value for seek times.
>
> The model also doesn't take into account that even with no
> fragmentation, there might be some seek operations: Blocks on an HDD are
> organized in rings (tracks), not as a spiral like the sound track on an
> good old LP. That means that at some point, the r/w head has to switch
> to the next track when the file does not reside on one track alone.
>
> [1] A bit off-topic: I work in applied sciences and engineering. There
> I've learned two basic rules about models: 1. Truth doesn't matter,
> usefulness does. 2. Every model has its limits. Knowing these limits is
> the single most important important thing when using a model.
>


Hmm, I've just looked up some specs from this page:
http://www.wdc.com/en/products/products.asp?driveid=512

These make me a wonder a bit:
Average latency is 5.5 ms. That's the time the disk needs for half a
rotation. However, read seek time is 12 ms. That's a bit more than one
rotation. If that's an average value rather than a maximum, it makes me
wonder what takes it so long. It can't be rotational delay (that's their
average latency). Therefore it must be the time it takes the r/w head to
move into position.

I find it a bit unbelievable that this takes so long. If that really is
the limiting factor then a high-end server disk couldn't be much faster
simply by increasing the RPM.

Well, I guess their "seek time" is the maximum value. Then it makes
sense: One rotation is 11.111 ms. Then they might add some latency due
to data processing etc. Any different thoughts?

Another interesting bit of information: Track-to-track seek time is 2
ms. That's the seek time I mentioned above which also occurs for
sequential reads/writes.

Regards,
Florian Philipp