SATA §

The payload rate is not a marketing rounding of the line rate — it follows from the coding. Work it through for SATA 3.0:

1. Line rate. The PHY clocks 6 × 10⁹ symbols per second, one bit per symbol (NRZ on a differential pair), so the wire carries 6 Gb/s.
2. Decode. 8b/10b maps every 8-bit payload byte to a 10-bit symbol chosen to keep the DC balance and enough transitions for clock recovery. Only 8 of every 10 wire bits are data: the payload rate is 6 × 10⁹ × 8/10 = 4.8 × 10⁹ bit/s.
3. Convert to bytes. 4.8 × 10⁹ ÷ 8 = 6 × 10⁸ bytes/s = 600 MB/s.

The same three steps give 150 MB/s for 1.5 Gb/s and 300 MB/s for 3 Gb/s — the payload is always exactly 80% of the line rate. Why pay 20%? Because 8b/10b guarantees a transition density and running-disparity balance that let the receiver recover the clock from the data itself, with no separate clock wire — the same trade-off every serial link of the era made (PCIe Gen 1/2, Fibre Channel, Gigabit Ethernet all use 8b/10b; see Cabled external interconnects for why serial won over parallel in the first place).

On cable length. Internal SATA is limited to 1 m; the external variant eSATA allows up to 2 m (the Gen1m/Gen2m specifications) but mandates shielded cable and connectors to get there. The 1 m internal limit is not arbitrary: at 6 Gb/s, attenuation and crosstalk eat the noise budget quickly. The SATA specification does not mandate the adaptive equalisation and link-training machinery that 10GBASE-T or PCIe Gen 3+ use to buy back margin on long channels; Gen 3 receivers in practice do include equalisation DSP to close marginal links, but the specification does not tighten the cable plant to extend the reach — hence 1 m, and 2 m only with eSATA’s shielding.

Splitting data from power is a deliberate simplification: the data connector stays small (a 2.5-inch drive is only 7 mm thick), and devices that need only one function can omit the other — an eSATA bracket carries data with no power, and a powered enclosure carries power with no host data path. Compare USB-C, which multiplexes power and data on one 24-pin plug and therefore needs a negotiation protocol (USB-PD) just to agree on volts and amps; SATA’s split is possible because both ends are fixed-function and the drive never negotiates its power rail.

Two details of the pinout repay attention:

• Grounds between the pairs. Pins 1, 4, and 7 are ground, so each differential pair is flanked by a ground on both sides. This isolates the transmit pair from the receive pair (less crosstalk at the connector, where the tight twist geometry ends) and lets the cable’s shield and drain wire bond to signal ground at defined points.
• Three pins per rail. Each power pin is rated 1.5 A, so a rail with three pins carries up to 4.5 A. A 3.5-inch drive’s spindle motor draws several amps at 12 V during spin-up — a single pin would be the thermal weak point, so the connector triples them.

Where the FIS comes from. SATA was designed for a frictionless transition from PATA, so its command FIS is a literal photograph of the old IDE task-file registers: the 8-bit command code, sector number, cylinder, drive/head, and count bytes that software used to write to I/O ports are carried field-for-field in the FIS payload. The same driver commands, the same register semantics — only the transport changed. This backward compatibility made adoption trivial, but it also caps the protocol: one command queue of depth 32, one device per cable, and a register-shaped command set that maps poorly to flash memory’s parallelism (see NCQ and AHCI below).

Framing and flow control. The link layer wraps every FIS between primitive symbols — a 32-bit control word repeated as needed: SOF opens the frame, CRC protects the payload, EOF closes it. Between frames, both sides stream SYNC to keep the receiver’s clock recovery locked. When a receiver’s buffers fill, it asserts HOLD; the transmitter pauses mid-frame and repeats HOLDA until HOLD drops. This is flow control without any credit accounting: the pause is signalled in-band, at symbol granularity, and costs nothing when unused.

The overhead budget. The 600 MB/s payload computed above is not all data. Each frame pays SOF/EOF primitives, a 4-byte CRC, and the FIS type header; between frames, SYNC and flow-control primitives flow continuously. A well-driven sequential transfer keeps this under ~10%, which is why a good SATA 3.0 SSD reports ~550 MB/s rather than 600 — the arithmetic is exactly the example problem below, and the simulation at the end of this page lets you move the numbers around.

The path of one read under AHCI (see the AHCI 1.3.1 specification for the register and memory layouts):

1. The OS fills a command table in RAM: a command header pointing to a Register FIS-to-device (the LBA and count, i.e. the task-file image) and a PRDT listing the DMA buffers for the data.
2. The OS sets the command’s issue bit in the port’s command register.
3. The AHCI controller DMA-reads the table, transmits the Command FIS, receives the Data FIS, and DMA-writes the data into the buffers — the CPU is not involved in the transfer.
4. The drive returns the Status FIS; the controller raises an interrupt and updates the done bits.

Why queue depth matters. With one outstanding command, a hard drive that takes 10 ms per random 4 KB read delivers 100 IOPS. With 32 outstanding, the drive’s scheduler can order them by head position, so the average seek per command drops and the commands overlap: even with no scheduling gain at all, pipelining alone lifts the ceiling to 32/0.010 = 3200 IOPS. NCQ is why the depth-32 queue — not bandwidth — is the number that matters for desktop hard-drive latency.

Hot-plug. SATA was designed for it from the start, unlike PATA: the data connector’s ground pins are longer than the signal pins, so grounding happens before any signal line mates (a “staggered” pinout), and AHCI controllers support mechanical presence detection and cold-presence-detect interrupts so the OS can enumerate a drive inserted into a live port. eSATA makes this mandatory; internal hot-plug is optional but common on server backplanes, where a failed drive is swapped without powering down the chassis.

Why the variants died or lived. mSATA and M.2 SATA carry the identical protocol over different physical cards — M.2 won because it is thinner, uses the same slot as NVMe drives, and needs no cable. SATA Express is the instructive failure: it tried to make one slot serve both SATA and PCIe, but a slot that runs at the slower standard’s speed whenever a SATA drive is inserted satisfies nobody, and M.2 (which simply wires the same pins differently per module type) replaced it within a few years.

The comparison is not “newer is faster” but a lesson in what legacy costs. SATA’s command model — one queue, depth 32, register-shaped FISes, one device per cable — was engineered for 2003’s hard drives, and every one of those choices is a ceiling for flash, which has no seek time to schedule around and many parallel NAND dies to keep busy. NVMe (see the NVMe specification) starts from PCIe’s point-to-point lanes — the physical layer is described in Board-level interconnects — and defines a scalable queue model that matches flash’s parallelism. The bandwidth ratio (3.94 GB/s vs 0.6 GB/s) is the smaller half of the story; the queue-depth and latency differences are what make NVMe drives feel faster at small random I/O.

SATA survives where its ceiling does not bind: hard drives (mechanically limited far below 600 MB/s), bulk storage, and budget SSDs — plus universal compatibility, since every OS and BIOS for 20 years speaks it.

A technician connects a 2.5-inch SATA drive with only the 7-pin data cable plugged in. The BIOS never enumerates the drive. Why, and what does this reveal about the connector design?