Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Keld Jørn Simonsen
I would like to have hdparm report more performance
measures, such as average seek time and track-to-track
Average seek time could be done by performing a number of random seeks,
done with small buffers.
I understand that track-to-track is not readily measurable, as
there is no correspondance on today's disk between the cylinder/
heads/sectors figures that a manufacturer publishes and the real
world. But still a disk is built from cylinders and heads and tracks,
and going from one track to another will occur, and a time delay
for this will occur. It is just hard to tell when. My idea is then
to have a number of random reads of some block sizes that are supposed
to sometimes include a track change, and sometimes not.
This would theoretically then group the transfer rates into two distinct
groups, where the difference would be the track-to-track seek time
Another measure would be the maximum and minimum transfre rates.
Eg. on a cd/dvd reader the transfer speed on the last part of the
disc can be more than twice that of the beginning of the disc.
These differences would then also be needed to calculate the
measurements mentioned above.
Would that be something desirable for hdparm? My thoughts were that
as hdparm already is a common tool for measuring disk speed via the
-t option, hdparm would be the most likely candidate for
this added functionality.
Keld Jørn Simonsen
I have made some patches to implement some of this - available at http://std.dkuug.dk/keld/hdparm-7.7-ks.tar.gz
this hdparm can calculate min and max transfer rates, and min/avg/max access times.
Okay, this is cute, and looks useful.
I just might add some of it, or something similar, to hdparm soon-ish.
But rather than using read(2) through the filesystem, it might be be better
in some cases (SATA drives) to use the SG_IO(ATA_16) ioctl (SAT interface)
to directly issue low-level commands.
Of course, that won't work for USB / Firewire / other drive types,
but for those we could fall-back to read(2), possibly with O_DIRECT
as an option (the existing hdparm --direct flag could serve here).
Those are my thoughts. If you want to update things and contribute code,
then please do so. Somewhere on the sourceforge place is a spot to contribute patches for hdparm, which I usually check just prior to each new release.
One possible way to check track-to-track seek time could be by using the READ VERIFY SECTOR(S) (EXT) command which is Non-Data and only measures the reliability of the read channels and their speed (DRDY set after each successful block read - would need to poll for this change somehow and check the delay).
Since each physical track could have between 300 to 1500 sectors (+/- a few hundreds), you would have to keep track of the timing for each block (sufficiently small so that the seek time is significantly bigger than the average read time for the block); when this value jumps you know that the heads have moved to the next track. There would probably be a bigger jump when you hit a zone boundary (12 or more zones are common; where the number of spt changes)
I imagine if you plot these values you would get a nice stair-step graph and you would be able to count the number of zones.
just a thought, let me know if this is helpful.