How is the average seek time of disk calculated if a function f(x)
is given as an estimate of time to move head of disk to n tracks?


migrated from dba.stackexchange.com Oct 31 '11 at 12:27This question came from our site for database professionals who wish to improve their database skills and learn from others in the community. 


The previous answer could've been accurate in 90s, when seek times were significant. In practice, in modern hard drives seek is very fast, and access time almost always dominated by latency  waiting before disk rotates enough so that the data is right under the head. Seek happens in parallel with rotation, so you aren't adding these up, you just look what's the slowest. Rotation is the slowest. For rotation avg to max ratio will be 1/2, not 1/3, so overall access ratio is 1/2. Making many small partitions to put related data on neighbor tracks is an outdated advice. Again, it was true in 90s, not true today. However, nowadays disks are formatted so that larger outer tracks have about twice as much data as the inner tracks. This doesn't change avg to max access time ratio, but this changes throughput near the beginning of the disk. So it's still worth partitioning so that the data you use more often (such as OS) will be in the beginning of the disk to get twice higher sequential read times comparing to the area close to the end of the drive. P.S. I've just created my account and I don't yet have enough reputation to answer @jitendra comment, so let me answer it here: "Why in general case, the average seek time is said to be 1/3rd of the max seek time?" If you have N tracks (numbered from 1 to N), we can compute average by looking at all distinct possibilities of starting track (i) and destination track (j). Travel distance will be abs(ji). Total distance: sum{ abs(ji) } for i=1..N,j=1..N. Number of points: N^2 Max distance: N Average distance: (sum{ abs(ji) } for i=1..N,j=1..N) / N^2. Avg/Max ratio will be (sum{ abs(ji) } for i=1..N,j=1..N) / N^3. Wolframalpha doesn't want to compute it unless I simplify it  I wil look only at cases where j > i, and then double the result to approximately account for symmetric cases:  Instead of sum{ abs(ji) } for i=1..N,j=1..N  I will use 2* sum{ ji } for i=1..N,j=i..N Rewriting it as nested sum in Wolframalpha syntax: 2*(sum(sum(ji) j=i to N) i=1 to N)/(N * N * N) Getting 1/3  1/(3*N^2). That's pretty much 1/3. But as I said earlier, it doesn't matter, because access time is dominated by latency not seek. 


It can be fully enumerated by calculating the seek time from all tracks to all other tracks and averaging the value. There are mathematical formulas which can be used to simplify the calculation. The provided value is a theoretical value based on truly random access. In practice, average seek time for a particular disk in use may be significantly different. This value will fall in between the seek time for a single track move, and the seek time between tracks at either end of the disk. Settle time can be a significant factor for small moves. Placing heavily accessed files and partitions close together can improve access times. This increases the effect of settle time on disk accesses. To make matters worse new disks have a different actual geometry than is described by the legacy HCS specification. The average seek time is more complicated in this case. One disk access optimization is to sift sectors between tracks so that sector 1 is located where it is the first sector read after a single track forward seek from the last sector on the previous track completes. EDIT: Using successive approximation, 1/3 of the max seek time is a good estimate. The limits of the average seek time will be between the limits; 0.5 max seek time (worst case, from edge of the disk) and 0.25 max seek time (best case, from center of the disk). For the two edges and the center, this averages 0.417. Average seek time from 1/4 of the way across the disk is ( 1/4 * 0.125 + 3/4 * 0.375 = 0.315 ). The average of these five samples is 0.376 which is closer to 1/3. The more samples you use the closer to 1/3 you will find the results. 

