Access Time Components

When a database requests data from a hard disk, the storage system doesn't respond instantly. Mechanical components must physically move, platters must rotate, and data must be transferred through multiple interfaces. Understanding the components of disk access time is fundamental to database performance engineering.

Why Access Time Matters:

Disk access time often dominates query execution time:

• A CPU can execute billions of instructions per second
• Main memory can be accessed in ~100 nanoseconds
• A single random disk access takes ~10 milliseconds

This gap—100,000× slower than RAM—means that reducing disk access count and optimizing access patterns has outsized impact on database performance.

In this page, we dissect every component of disk access time, providing the quantitative foundation for understanding why databases are designed the way they are.

The total time to access data on a disk is the sum of several components:

Total Access Time = Seek Time + Rotational Latency + Transfer Time + Controller Overhead

Component Breakdown:

Order of Magnitude:

For typical random access:

• Seek: ~8 ms
• Rotation: ~4 ms
• Transfer (1 sector): ~0.01 ms
• Overhead: ~0.2 ms
• Total: ~12 ms per random I/O

This means maximum random IOPS ≈ 1000 ms / 12 ms ≈ 80-100 IOPS per drive.

The Dominance of Mechanical Latency:

For random access patterns:

• Seek + rotation account for ~99% of access time
• Transfer time is negligible for small reads
• Reducing seeks and optimizing rotation are critical

For sequential access patterns:

• Single initial seek + rotation
• Subsequent accesses are transfer-time limited
• Throughput approaches maximum transfer rate

Seek time is the duration required for the actuator arm to move the read/write heads from their current position to the target cylinder. It is typically the largest component of random access latency.

Seek Time Components:

The seek operation consists of three phases:

1. Acceleration — Voice coil motor accelerates the arm assembly
2. Coast/Slew — Arm travels at maximum velocity (for long seeks)
3. Deceleration and Settle — Arm slows down and precisely positions over target track

Seek Time Specifications:

Drive specifications include several seek time metrics:

• Track-to-Track Seek: Moving to adjacent cylinder (~0.5-1 ms)
• Average Seek: Statistical average across all possible seeks (~8-12 ms)
• Full Stroke Seek: Innermost to outermost cylinder (~15-25 ms)
• Read Seek vs Write Seek: Write may be slightly longer (more precise positioning required)

The Seek Time Formula:

Seek time as a function of distance is approximately:

T_seek = a + b × sqrt(d)

Where:

• d = number of cylinders to traverse
• a = fixed overhead (arm startup, settling)
• b = coefficient based on arm speed

The square root relationship occurs because:

• Arm accelerates for first half of distance
• Arm decelerates for second half
• Time = 2 × sqrt(2 × distance / acceleration)

Why Average Seek ≠ Half of Full Stroke:

For uniformly distributed random seeks, the average distance is one-third of the maximum distance, not one-half. This is because:

• More cylinder pairs are close together than far apart
• Integral calculation shows E[distance] = (max_cylinders) / 3

Therefore, average seek time is less than half of full stroke time.

Rotational latency (also called rotational delay) is the time waiting for the desired sector to rotate under the read/write head after the seek completes.

The Rotation Dynamics:

After the head reaches the target track, it must wait for the correct sector:

• Best case: Sector arrives immediately (0 latency)
• Worst case: Just missed, full rotation required
• Average case: Half a rotation (statistically)

Calculating Rotational Latency:

Time per Revolution = 60,000 ms / RPM

Average Rotational Latency = (Time per Revolution) / 2

Rotational Latency Variance:

Unlike seek time (predictable based on distance), rotational latency is essentially random:

• Follows a uniform distribution from 0 to full rotation time
• Cannot be predicted without knowing current sector position
• Variance = (rotation_time)² / 12

The Rotational Position Sensing (RPS) Optimization:

Some drives and controllers implement RPS to reduce rotational latency waste:

1. When issuing a seek, controller calculates expected arrival time
2. Compares to target sector position at that time
3. May delay issuing the seek to minimize total time
4. Called "rotational position optimization" or "command ordering"

Head Switching and Rotation:

When switching heads within a cylinder:

• New head position may not align with previous
• Small rotational wait may be needed
• Drive firmware accounts for this in access optimization

Transfer time (also called data transfer time or read/write time) is the duration to transfer data between the platter surface and the drive's buffer, and subsequently to/from the host system.

Transfer Time Components:

1. Media Transfer — Data read from platter to drive buffer
2. Interface Transfer — Data moved from drive buffer to host memory

Typically, media transfer is the bottleneck for HDDs, while interface transfer may bottleneck older connections.

Calculating Transfer Time:

Transfer Time = (Data Size) / (Transfer Rate)

Where transfer rate depends on zone (outer zones are faster due to ZBR) and drive specifications.

Zone-Dependent Transfer Rates:

Due to Zone Bit Recording (ZBR), transfer rates vary significantly:

• Outer zones (low LBAs): 180-250 MB/s
• Middle zones: 140-180 MB/s
• Inner zones (high LBAs): 90-130 MB/s

This ~2x variation means:

• Benchmark results depend heavily on test location
• Data placement affects throughput
• Short-stroking (using only outer zones) significantly improves sequential performance

Interface Bandwidth:

The drive interface must keep up with media transfer rates:

Beyond the mechanical components, additional time is consumed by command processing, data movement through the I/O stack, and controller operations.

Sources of Overhead:

1. Command Parsing — Drive interprets the SATA/SAS command
2. Buffer Management — Data moved to/from drive cache
3. ECC Processing — Error correction encoding/decoding
4. Host Interface — Protocol overhead (command queuing, response)
5. Operating System — I/O scheduler, driver, interrupt handling
6. File System — Block allocation lookup, metadata updates

Total Overhead Impact:

Combined overhead is typically 0.1-0.5 ms, which is:

• Negligible for random I/O (dominated by ~12 ms seek + rotation)
• Significant for sequential I/O (can limit small-block sequential performance)
• Critical for SSDs (overhead becomes dominant when mechanical latency is zero)

Cache Hit Shortcut:

When data is found in the drive's buffer cache:

• Seek and rotation are eliminated
• Response time is purely overhead (~0.1-0.3 ms)
• Drive cache hit rate depends on workload locality and cache size

Write Cache and Synchronous Writes:

Writing behavior significantly affects overhead:

• Write cache enabled: Data acknowledged when in drive buffer (~0.1 ms)
• Write cache disabled / FUA: Data acknowledged after media write (~12 ms)
• Database transaction safety usually requires disabled cache or battery backup

Let's work through detailed access time calculations for various scenarios, building intuition for performance analysis.

Example Drive Specifications:

• RPM: 7200
• Average Seek: 9 ms
• Max Transfer Rate: 200 MB/s (outer zone)
• Min Transfer Rate: 100 MB/s (inner zone)
• Average Transfer Rate: 150 MB/s
• Sector Size: 4 KB
• Controller Overhead: 0.2 ms

Rotational Latency:

Time per revolution = 60,000 / 7200 = 8.33 ms
Average rotational latency = 8.33 / 2 = 4.17 ms

*Sequential access: First I/O pays seek + rotation; subsequent reads are transfer-limited.

IOPS Calculations:

From access times, we can calculate maximum I/O operations per second:

Random IOPS = 1000 ms / access_time
Random 4 KB IOPS = 1000 / 13.4 ≈ 75 IOPS

Throughput Calculations:

Random Throughput = IOPS × I/O size
Random 4 KB Throughput = 75 × 4 KB = 300 KB/s = 0.3 MB/s

Sequential Throughput:

Sequential Throughput ≈ Transfer Rate = 150 MB/s (average)
Sequential IOPS (4 KB) = 150 MB/s / 4 KB ≈ 38,400 IOPS

The 500× Difference:

Random vs Sequential IOPS: 75 vs 38,400 (>500× difference!) This massive gap explains why databases work so hard to convert random access to sequential.

Modern drives and interfaces support command queueing, allowing multiple I/O requests to be outstanding simultaneously. This enables the drive to optimize access order and significantly improves effective performance.

Native Command Queueing (NCQ) - SATA:

• Supports up to 32 outstanding commands
• Drive reorders commands to minimize seek distance
• Host can issue commands without waiting for previous completion
• Dramatically improves random I/O throughput

Tagged Command Queueing (TCQ) - SAS:

• Supports up to 256 outstanding commands
• Full command scheduling control
• Better suited for enterprise multi-path environments

How Queueing Reduces Access Time:

1. Seek Reduction: Commands sorted by cylinder for elevator-style access
2. Rotational Optimization: Issue command for sector arriving soonest
3. Write Combining: Coalesce adjacent writes
4. Read-Ahead: Speculatively fetch following sectors

Database Implications:

High queue depth benefits database workloads by:

• Reducing effective latency for parallel queries
• Improving throughput during bulk operations
• Enable asynchronous I/O patterns

However, fairness concerns arise:

• One query's heavy I/O can delay others
• I/O priority and scheduling become important
• Some databases limit queue depth per connection

Asynchronous I/O:

Databases often use asynchronous I/O (AIO) to maximize queue depth:

// Synchronous (blocks until complete)
read(fd, buffer, size);

// Asynchronous (returns immediately, checks later)
io_submit(ctx, 1, &iocb);
// ... do other work ...
io_getevents(ctx, 1, 1, events, timeout);