** This is the quasi-official and semi-temporary T13 email list server. **
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! 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.
>[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?
Do you know the zone layout? Do you know if the drive does
small seeks faster than a head switch (most do!)? Do you
realize that with write caching on all write commands have
virtually zero "command overhead"? Do you realize that many
drives can execute 5, 10, maybe a 100 commands all in hardware
without the drive's firmware getting involved? 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? 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!
I'm done for now... Someone else's turn!
*** Hale Landis *** [EMAIL PROTECTED] ***
*** Niwot, CO USA *** www.ata-atapi.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]
