Bug 104775 - wrong numbers in 5.4. Hard Drive Performance Characteristics
wrong numbers in 5.4. Hard Drive Performance Characteristics
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: rhl-sap (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ed Bailey
Tammy Fox
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-20 21:03 EDT by D. Hugh Redelmeier
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-21 11:12:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description D. Hugh Redelmeier 2003-09-20 21:03:20 EDT
I'm looking at 5.4 of rhl-sap(EN)-9-HTML-RHI (2003-02-20T01:08)

5.4.1.3 says of rotational latency: "This averages .05 milliseconds for a 10,000
RPM drive."

I calculate that a single rotation takes 6ms (60 seconds / 10000 RPM).  So an
average rotational latency would be a little more than half of this -- about 3ms
(60 times your figure).

(Why "a little more": because landing in the middle of a sector does not make
that sector immediately available.  The 50% timing starts from the first sector
start encounted.  By your model, this would add perhaps 1/1400th of a rotational
period to the figure.  Small enough to ignore.)

5.4.1.2 says of read/write time: "This averages .00014 milliseconds for a 10,000
RPM drive with 700 sectors per track."

I calculate that 1/700th of a rotation would take .00857ms.  Some of the track
may be taken up by labels and gaps, but surely not as much as 50%.  So the
read/write time must be at least .0043ms (30 times your figure).

It looks to me as if you assumed the 10000 RPM meant 10000 rotations per second,
not rotations per minute.

Other calculations in this section ought to be checked.
Comment 1 Ed Bailey 2003-09-21 11:12:44 EDT
Thanks for your report.  You are absolutely correct, I mixed up my units
(minutes and seconds) and got mixed-up answers as a result. :-)

I'm going with the .00857 (rounded to .0086) msec number for track writing, as
it's a worst-case number (and it makes little difference in the overall access
time figure anyway).

The updated figures will appear in the next release of this document.  Thanks
again for letting us know!


Note You need to log in before you can comment on or make changes to this bug.