** This is the quasi-official and semi-temporary T13 email list server. **
I believe that the command turnaround is very important in sequential mode
due to the possibility of read ahead being terminated before the next
command is received (which would normally have the effect of extending read
ahead). Spinning revs in sequential mode causes big performance
degradation. In a random sequence, I do not believe that command turnaround
has much of an effect other than increasing the time that the host is
inserting into the overall command start to command start time.
- Jim W
Jim Wilshire
Sr Staff Eng. System Architecture
Keen Personal Media, Inc.
The PVR Solutions Company
www.keenpm.com <http://www.keenpm.com>
P. +949.672.6224
F. +949.672.6211
[EMAIL PROTECTED]
THE INFORMATION CONTAINED IN THIS TRANSMISSION IS CONFIDENTIAL AND MAY ALSO
CONTAIN PRIVILEGED ATTORNEY-CLIENT INFORMATION OR WORK PRODUCT. THE
INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM
IT IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, OR THE EMPLOYEE OR
AGENT RESPONSIBLE TO DELIVER IT TO THE INTENDED RECIPIENT, YOU ARE HEREBY
NOTIFIED THAT ANY USE, DISSEMINATION, DISTRIBUTION OR COPYING OF THIS
COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS
COMMUNICATION IN ERROR, PLEASE IMMEDIATELY NOTIFY US VIA RETURN E-MAIL OR BY
TELEPHONE AT (800)-556-2000.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, May 17, 2001 11:24 PM
To: [EMAIL PROTECTED]
Subject: [temp t13] Re: ATA speed test
** This is the quasi-official and semi-temporary T13 email list server. **
*** Hale Landis *** [EMAIL PROTECTED] ***
*** Niwot, CO USA *** www.ata-atapi.com ***
>>May I make a suggestion? As in the ATA6 AV Feature Set
>>proposal a good definition of the command completion time
>>would be the time from the command register being
>>written to the last interrupt of the last sector transferred.
>That sounds like the definition that has been used for the last 50
>years to measure command execution time.
I then assume that everyone agrees that this is correct.
>>This allows true device performance to be measured, but requires
>>that the IDE driver, and associated structure includes a mechanism
>>to transfer the times beyond the kernel. This is highly OS specific, I
>>know, but it is the only true way to HDD performance without dedicated
>>hardware.
>Most hard disk performance measurement is by strange and poorly
>designed applications programs written by people that (in my
>experience and my opinion) really do not understand what they are
>doing and what they are trying to measure. An OS that had some device
>driver interface that returned the command execution time would
>certainly lead to even more of this software.
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. That is all I would like to say.
>>At Philips we have modified the request structure to include a Start
>>Time and a Finish Time for a request. In such a way very accurate
>>HDD performance can be measured, such as head & track skews,
>>for example.
>But do you also return the time from the end of the previous command
>to the beginning of the command that was just executed? If you are
>not measuring that time then, I'm sorry, you are missing the SINGLE
>MOST IMPORTANT THING THAT AFFECTS HARD DISK DRIVE PERFORMANCE,
>ESPECIALLY CACHING PERFORMANCE.
Hale, you probably have a valid point that you would like to make here,
but I cannot extract it from this sentence. Would you please describe
what you are implying? If so, by direct email.
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.
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]
--
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]
