Seek Time, Rotational Latency, and Why the Average Is Not the Middle

A disk access is not one operation. It is a mechanical move to the right radius, a wait for the platter to bring the right sector under the head, and then a transfer. Each part has a different distribution, and the distributions are not uniform, which is why the widely quoted “average seek time” on a datasheet is neither the mean nor the median of the seeks a real workload performs.

Three mechanical stages

The actuator is a voice-coil motor that pivots an arm carrying the head stack. Its input is current; its output is angular position, which maps to a track radius. The dynamics are those of a mass-spring system with a flexible mode: the arm is stiff enough to move quickly but not stiff enough to stop instantly without ringing.

A seek therefore runs as a trajectory, not a step. The controller computes a velocity profile — accelerate, coast, decelerate — and drives the coil to follow it, using the head’s position error signal from the servo fields as feedback. For short seeks the profile is a simple accelerate-and-brake; for long seeks the arm reaches a maximum velocity limited by the coil’s force and the available travel. The time for the move is roughly the square root of the distance in the acceleration-limited regime, then linear in distance once the velocity limit binds. A seek across a third of the stroke is a different regime from a seek of one track.

After the arm arrives, the head is not yet on track. Residual oscillation from the deceleration, plus the reaction of the whole drive chassis, leaves a position error that must decay before the head can read or write reliably. This is the settle phase, and it is why short seeks are not much cheaper than medium ones: the fixed cost of settling is a large fraction of the total. A one-track seek and a ten-track seek may differ by a small amount because both spend most of their time waiting for the arm to stop wobbling.

Rotation is the third stage, and it is independent of the first two. The platter spins at a constant rate, and the target sector arrives at the head after a delay uniformly distributed between zero and one revolution. That uniformity is the one clean piece of the model: at a spin rate of tens of revolutions per second, a full revolution takes several milliseconds, so the expected rotational delay is half of that, a few milliseconds.

Why the mean seek is not half the maximum

Datasheets quote a single number, typically described as an average seek time, and the value is not the arithmetic mean of a uniform distribution over all track distances. Two effects move it away from that figure, in opposite directions.

The first is the trajectory. In the acceleration-limited regime seek time grows as roughly the square root of distance, and it becomes linear only once the arm reaches its velocity limit. The time-versus-distance curve is therefore concave: steep over the first few tracks and flattening toward the stroke limit. A concave curve that starts above zero lies above the straight line joining its endpoints, so the mean over a uniform distribution of distances is greater than half the full-stroke time, not less. Short seeks are what a concave profile punishes — cheap in absolute terms, expensive per track covered — and the fixed settle cost pushes the mean up for the same reason.

The second is the workload. Real access patterns are not uniform over the surface. Files are allocated in extents, metadata sits near the start of the volume, and a filesystem that lays out related blocks adjacently produces many short seeks and a few long ones. A workload with locality has a mean seek far below the uniform figure; a workload of independent random accesses over a large volume has one close to it. Neither number is the datasheet’s.

The honest way to read the specification is as a bound and a shape: the full-stroke time is the worst case, the track-to-track time is the floor, and the real value is a function of the access pattern’s locality. A datasheet average is defined by the vendor’s own measurement — a random seek over a stated cylinder range, an average over a nominated distribution — so it is comparable within a product line and not outside one. Benchmarks that report a single latency for random access are reporting the mean of a distribution whose tail is much longer than its head, and the tail is what determines the queue depth a workload can sustain.

Queueing converts latency into throughput

A single disk serving one request at a time delivers throughput equal to one access time per request: at a few milliseconds per access, a few hundred operations per second. That number is a property of the mechanics, not of the interface, and no amount of buffering changes it.

What changes it is reordering. Because the drive can hold several requests and choose the order to serve them, it can turn a set of random accesses into a shorter total travel. Serving requests in the order that minimises arm movement — an elevator sweep from one radius to the other and back — reduces the mean seek across a batch at the cost of unfairness: a request near the current position is served quickly, one just missed waits for a full sweep.

The scheduler’s choice is a trade between latency and throughput, and the classic result is that shortest-seek-first minimises mean response time when all requests are known in advance but starves requests at the far end of the stroke. Elevator scheduling bounds the worst case at the cost of a higher mean. Both assume the queue is deep enough to reorder, which is why queue depth is the parameter that matters: with a depth of one, no scheduling is possible and the device delivers its single-request latency.

Modern drives do the reordering internally and expose a queue. The interface’s queue depth is tens to hundreds of entries in the common serial-attached command sets, and the drive’s firmware decides the order, informed by the logical-to-physical mapping it maintains. The host’s I/O scheduler becomes a second layer that batches and merges requests before they reach the drive, and the two layers can conflict: a host that issues requests one at a time defeats the drive’s reordering, and a host that issues a deep queue of dependent requests gives the drive nothing to reorder.

/* Expected service time for a batch served in elevator order versus FIFO,
   using a simplified linear seek model. Illustrative, not measured. */
struct req { double track; };

static double seek_cost(double from, double to, double per_track, double fixed)
{
    return fixed + per_track * (to > from ? to - from : from - to);
}

double sweep_cost(const struct req *q, size_t n, double start, double per_track,
                  double fixed)
{
    double t = 0.0, pos = start;
    for (size_t i = 0; i < n; i++) {         /* requests pre-sorted by track */
        t += seek_cost(pos, q[i].track, per_track, fixed);
        pos = q[i].track;
    }
    return t;
}

The model is deliberately crude, but it captures the structural point: a sorted batch pays for the sweep across the whole span once, while an unsorted batch pays a random jump per request. With a fixed cost that dominates short seeks, sorting gains little until the batch spans many tracks — which is exactly the regime where the drive’s own reordering matters most.

Caches, and what they actually hide

Drives carry a volatile write cache and a read cache. The write cache absorbs writes and acknowledges them before they reach the medium, which converts a host-visible latency into a queueing delay inside the drive. The read cache holds recently read sectors and, more importantly, performs read-ahead: when the host reads a sector, the drive fetches the following sectors of the track into the cache, on the assumption that sequential access is common. Both caches exploit the same property, that the medium’s cost is dominated by positioning and the transfer of adjacent data is nearly free once positioned.

The write cache’s benefit is bounded by the drive’s ability to flush. If the host writes faster than the medium can absorb, the cache fills and the acknowledgement latency rises to the medium’s rate. The drive also has to flush the cache on command, and a flush after a burst of random writes costs the full repositioning time for each cached sector’s target, in an order the drive chooses. This is why a workload of small synchronous writes with a flush after each one is far slower than the same bytes written asynchronously: the flush forces the cache to be drained and the drain is a sequence of random accesses.

What the numbers imply for layout

The practical consequence is that placement dominates. A file stored as one contiguous extent costs one seek and one rotational wait for the whole file; the same file scattered over the surface costs one per fragment. A filesystem that allocates sequentially and keeps fragmentation low is exploiting the drive’s mechanics, and one that interleaves small allocations across the volume is fighting them. On a shingled medium the same argument becomes a hard constraint rather than an optimisation, because a write outside the current position forces a rewrite of the rest of the band; shingled recording and the write cursor covers what that does to the interface. The same reasoning explains why RAID striping across several drives multiplies throughput for large transfers: each drive pays its own positioning cost in parallel, and the aggregate rate is the sum of the individual rates as long as the transfers are large enough to amortise the positioning.

It also explains where solid-state storage changed the model. A flash device has no positioning cost, so its latency distribution is narrow and its queueing behaviour is dominated by the controller’s parallelism rather than by reordering. The parallelism is a separate mechanism, described in channel, die, and plane parallelism in flash controllers, and it produces a throughput curve that rises with queue depth for a different reason: not because the device reorders, but because it can serve several requests at once.