Encoding, Overhead and Usable Bandwidth

What a per-lane rate figure names, and what it leaves out

A figure in gigatransfers per second describes the wire, not the payload. It counts the symbols a lane clocks out in a second, not the part of them that is data. On the earliest PCI Express lanes the bookkeeping took a fifth of the line. Each generation roughly doubles the raw rate and, when the arithmetic demands it, changes the encoding underneath, so a table's two columns tell different stories: speed, and how much of it you keep. The figures below are attributed as they go; the same numbers, without the argument, sit in the link speed table.

A lane rate counts symbols. Encoding decides how many of those symbols are yours.

Ten bits on the wire for every eight of payload

The encoding written 8b/10b puts ten bits on the wire for every eight of payload: a fixed 20 percent of the line spent on something other than data. PCI Express 1.0 and 1.0a, dated 2003, and the 1.1 revision of 2005, run 2.5 GT/s per lane on it, about 250 MB/s useful per lane, per direction. The 2.0 generation of 2007 doubles the raw rate to 5.0 GT/s and keeps the encoding, so the useful figure doubles to about 500 MB/s. A 2.1 revision is dated 2009; its exact publication date was not confirmed beyond that year in the material read here.

That share holds at one fifth across the doubling, and carrying it forward unexamined is what the next generation punishes.

Why does 8 GT/s carry nearly twice the data of 5 GT/s?

PCI Express 3.0, finalized and published by PCI-SIG on 18 November 2010, raises the raw rate to 8.0 GT/s per lane, 1.6 times the previous figure, and changes the encoding to 128b/130b, carrying 128 payload bits in every 130. Line overhead falls from about 20 percent to roughly 1.54 percent, and useful throughput lands at about 0.985 GB/s per lane, per direction.

The same generation introduced transmitter and receiver equalization, PLL improvements, clock data recovery, and channel enhancements, the cleanup a denser encoding demands, agreed while the link trains rather than wired in. A 3.1 revision followed around 2013 to 2014, still at 8.0 GT/s; its exact date is one this desk could not confirm.

The same encoding for three generations, then a break

After 3.0 the ladder resumes and the encoding holds. PCI Express 4.0, released 8 June 2017, runs 16.0 GT/s per lane at 128b/130b, about 1.969 GB/s useful. PCI Express 5.0, released 29 May 2019, runs 32.0 GT/s, about 3.938 GB/s. Twice the raw rate, twice the payload, overhead unchanged.

PCI Express 6.0, released 11 January 2022, breaks the pattern. It moves to PAM4, a four-level pulse-amplitude modulation, at 64.0 GT/s per lane, with low-latency forward error correction, because PAM4 alone is noisier than two-level signaling and needs those codes to stay reliable. FLIT mode becomes mandatory: payload travels in fixed 256-byte blocks of 242 usable bytes. PCI Express 7.0, released 11 June 2025, doubles the raw rate again to 128.0 GT/s on the same signaling, for about 15.125 GB/s.

The byte column rests on a secondary source, the PCI Express page on Wikipedia, read on September 6, 2026. Day-and-month dates hold from 3.0 onward; the two earliest generations are dated by year alone. One cross-check covers the newest row: the Linux kernel's error-recovery documentation cites revision 7.0 of the base specification, which agrees with a 2025 release.

Where does a rate table actually come from?

The rate column can be checked against a document the desk read: the PHY Interface for the PCI Express, SATA, USB 3.2, DisplayPort and USB4 Architectures Specification, revision 7.1, September 2025, Intel reference number 643108. Its rate tables name PCI Express signalling rates of 2.5, 5.0, 8, 16, 32, 64 and 128 GT/s, each with the PCLK frequencies and interface widths a PHY may present for it. Its layer table names the encodings a PHY may implement, among them 8b/10b and 128b/130b, and its table of contents ties 128b/130b to PCIe 8, 16 and 32 GT/s.

It publishes no usable byte rates. The column above is arithmetic on rate and encoding, not a figure the specification quotes back, and the encoding entries at 64 and 128 GT/s rest on the secondary source, since the layer table read for this page does not describe the modulation at the two highest rates. The interface underneath those tables is described in what the PIPE interface is.

Recomputing a bandwidth figure before you build on it

The check runs on paper. Take the raw rate a document quotes, find the encoding the same document names for it, and apply the fraction: 0.8 at 8b/10b, 128 over 130 at 128b/130b. At the two highest rates the fraction stops being one clean ratio, because framing and correction share the line, and the stated quantity changes shape into 242 usable bytes per 256-byte block.

Keep the 3.0 row at hand when one of these numbers is argued over: a raw increase of 1.6 that produced nearly twice the payload is the plainest evidence here that the encoding column, not the rate column, decides what a lane delivers.