Bug 104775 - wrong numbers in 5.4. Hard Drive Performance Characteristics
Summary: wrong numbers in 5.4. Hard Drive Performance Characteristics
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rhl-sap
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ed Bailey
QA Contact: Tammy Fox
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-09-21 01:03 UTC by D. Hugh Redelmeier
Modified: 2007-04-18 16:57 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-09-21 15:12:44 UTC
Embargoed:


Attachments (Terms of Use)

Description D. Hugh Redelmeier 2003-09-21 01:03:20 UTC
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 15:12:44 UTC
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.