** This is the quasi-official and semi-temporary T13 email list server. **
Dear Hale,
>I really do hate to discuss disk drive performance, however, ...
>
>And I will apologize now for being so, how shall I say this,
>rude? But these sort of statements really bug me!
>>[EMAIL PROTECTED] said: "In general you are correct,
>>but then there are exceptions. Some people like to fully
>>characterise HDD's by measuring head & cylinder skews, transfer
>>rates by zone, HDD command overhead, seek time versus seek
>>distance etc etc. In these cases such an interface provides the
>>accuracy required."
>Even if you think you can measure head and cylinder (oh, don't
>forget zone) skews from the interface using standard commands (I
>hate to tell you this but this is big waste of time), how do you
>know the data you get from one drive will look anything like the
>data you get from another drive of the same brand and model and
>having a serial number one greater? YOU DON"T!
I can assure you that it is possible to extract head skew, cylinder
skew, sectors per track, zone tables for ATA IDE drives using standard
data commands. This is much easier when the drive supports the
disabling of read and write caching, but not essential.
It seems from your answer that you have never performed such measurements.
I am quite surprised at this, knowing your experience.
Although, we do not characterise a drive family, but a drive. General
design rules are fixed for a drive famliy such as formatting, firmware
etc. When purchasing HDD's in large numbers, of course we would expect
to be informed of major changes.
I agree with you that each drive is different, due to factory found
defects and grown defects. Note, however that these can also be
detected, so we do have an idea, which I believe is your next point.
>You have no idea
>how the factory defects are distributed, no idea how the sectors
>are arranged (and this is not a simple as you think it is). And
>I wonder how many people realize that lower capacity drives are
>just that because the drive would have been a full capacity drive
>except one of the heads was defective? Please, when you make
>statements about "characterize" a drive it tells me you really
>don't understand disk drives or what you are measuring. How do
>you even know if a drive is "seeking" between two LBA addresses?
>You might be surprised to find that two LBA addresses that are
>1000's or 100000's or even 1000000's apart map to physical
>sectors that are very close on the media. What you think should
>be a big seek might not be a seek at all.
We measure the complete seek curve as a function of seek distance
and yes sometimes strange servo code based effects appear, but that
is exactly what we are checking for. We want predictable HDD's
>>[EMAIL PROTECTED] said: "I can only assume that you
>>are mean HDD command overhead or OS overhead. All I can say is
>>that we characterise HDD's not OS's and we do measure HDD command
>>overhead."
>Say what?
>Actually I was not talking about OS overhead or device overhead
>but simply the amount of time from the end of one command to the
>start of the next command. This is generally application data
>processing time related. And this time has a huge impact on
>drive performance. But hardly anyone pays any attention to it.
>But back to my "Say What?" which was a comment about measuring
>"HDD command overhead"... Just what you are measuring anyway and
>how are you measuring it? Are you calling the time from when the
>command register is written to when the device sets BSY=0+DRQ=1
>the command overhead? You do understand that on write commands
>most drives will have BSY=0+DRQ=1 within 400ns? And on read
>commands that access cached data within 1us?
>So let me ask a few questions here...
>Do you know the logical LBA to physical LBA mapping for a drive?
We can extract enough information from command timing to model
the HDD based on what you would term a physical LBA mapping.
This is providing that the timing information is accurate enough.
Sectors or tracks that have re-assigned are exceptions to the model,
but this is also interesting for us since this is when the drive
becomes less predictable.
>Do you know the zone layout?
Again, this can be extracted from command timing. We do this, so
please do not say it is impossible. It has been confirmed against
information supplied by HDD vendors for a number of drives.
>Do you know if the drive does small seeks faster than a head switch
(most do!)?
We can identify the difference between a track to track seek and a
head switch, but this level of detail is not important for our
HDD model.
>Do you
>realize that with write caching on all write commands have
>virtually zero "command overhead"?
Caching of any form complicates the characterisation, but with some
effort even the effect of caching can be excluded from the timing
commands.
> Do you realize that many
>drives can execute 5, 10, maybe a 100 commands all in hardware
>without the drive's firmware getting involved?
Correct, this is drive dependant, but even the hardware has an overhead.
This is typically seen as missed rotations when sequentially reading and
the read cache is disabled. As you know, this is due to a maximum of
256 sector per ATA read command (solved for 16 bit sector counts,
thankfully).
>Do you know that
>many drives will recognize the seek and read/write patterns of
>the most popular "performance measurement" software and adjust
>their caching operations so they look better while running that
>test?
We do not use any commercial benchmark program. We write our own code
and algorithms to extract details from the HDD.
>If you issue a bunch of seek commands without reading or
>writing data do you know if the drive is really doing the seek
>you think it should?
>Do you know if it is doing any seek at all?
>It might not even be spinning while you think you are doing those
>seek commands!
Most often seeks commands are ignored by drives, as you imply form this
question. Single sector reads and writes with cache disabled can be
used, giving a timing error of a few tens of microseconds. This is
acceptable for most seeks that take milliseconds to complete,
>I'm done for now... Someone else's turn!
>*** Hale Landis *** [EMAIL PROTECTED] ***
>*** Niwot, CO USA *** www.ata-atapi.com ***
p.s. Thanks for reading my emails. Although I haven't learnt anything new yet, I'm
sure I will.
(This is not meant in any derogatory way)
Kine regards,
Stephen.
--
Dr. Stephen Cumpson, Senior Scientist,
Group Storage Technologies, Building WY 1 45, (WY12),
Philips Research Labs., Prof. Holstlaan 4, 5656 AA Eindhoven, The Netherlands
Tel.: +31 40 274 2762 Fax: +31 40 274 4927
Email: mailto:[EMAIL PROTECTED]
Web: http://www.research.philips.com/
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
