Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from dba.stackexchange.com Oct 31 '11 at 12:27

This 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(j-i). Total distance: sum{ abs(j-i) } for i=1..N,j=1..N. Number of points: N^2 Max distance: N Average distance: (sum{ abs(j-i) } for i=1..N,j=1..N) / N^2. Avg/Max ratio will be (sum{ abs(j-i) } 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(j-i) } for i=1..N,j=1..N -- I will use 2* sum{ j-i } for i=1..N,j=i..N

Rewriting it as nested sum in Wolframalpha syntax: 2*(sum(sum(j-i) 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.

share|improve this answer
1  
It is not entirely accurate that you simply take the maximum of the two numbers. The disk doesn't stop rotating if it reaches the right spot before the seek has completed. So you do need to account for the full seek time followed by waiting for rotation. (I don't know if any disks are intelligent enough to predict whether a seek will complete before the target sector rotates under the head and use said information to better schedule multiple requests in the queue simultaneously.) – kasperd Sep 30 '15 at 10:28
    
Yes, I think you're right. However, to be even more precise, it's not exactly sum of two numbers. You'd only skip a full rotation in those cases where the position you want was close enough so that the seek was too slow. So, instead of averaging times from 0 to Rot (and getting Rot/2), you'd need to look at two cases: average from Seek to Rot (the case when seek was fast enough), weighted by (Rot-Seek), and Rot to Rot-Seek, weighted by Seek. What I am getting is Rot/2 + Seek - Seek^2/Rot, not just Rot/2 + Seek. – morfizm Oct 1 '15 at 10:52
    
If the disk doesn't taking the current rotational position into account while scheduling the order of requests, then the rotation position at the end of the seek will be uniformly spread across the entire 360 degrees. So after the seek you will have an average of half a rotation delay to reach the correct position. – kasperd Oct 2 '15 at 10:39
    
I am not arguing average half a rotation delay, I just wanted to clarify that the impact of waiting a full rotation due to missed seek is small in case if seek time is small, because it means lesser chance this will happens. By the way, I am 99.99% sure all disks that have native queuing are smart enough to predict rotation positions and schedule accordingly. It sounds like a no-brainer optimization simple to implement that will just increase perf. I wouldn't be so sure about OS-level queueing though, it's much more difficult to control all aspects of timely data exchange. – morfizm Oct 3 '15 at 11:46
    
I don't know enough about the internals of harddisks to judge how difficult it is to predict the rotational delay after a seek. Certainly some of the data in the track itself will tell it which sector is under the head at this very moment. How accurately can the location of a sector be predicted before the head is on the right track? – kasperd Oct 3 '15 at 11:57

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.

share|improve this answer
    
Why in general case, the average seek time is said to be 1/3rd of the max seek time? – jitendra Oct 31 '11 at 0:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.