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.

Close

disk performance, avg seek time, track2track

2007-06-26
2013-04-27
  • I would like to have hdparm report more performance
    measures, such as average seek time and track-to-track
    seek time.

    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.

    Best regards
    keld

     
    • 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.

       
      • Mark Lord
        Mark Lord
        2008-06-05

        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.

        Cheers

        Mark (author/maintainer)

         
    • Frank Maloney
      Frank Maloney
      2008-02-04

      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.

      cheers,
      Frank