Throughput Efficiency Calculator

Throughput efficiency expresses the data rate a link actually delivers as a fraction of its nominal signalling capacity. The gap between the two is structural rather than accidental, because every layer of the stack spends bits on framing that carry no user payload. A standard Ethernet frame carrying a 1500-byte MTU adds a 14-byte header, a 4-byte frame check sequence, an 8-byte preamble and a 12-byte interframe gap, while IPv4 and TCP take a further 20 bytes each, leaving 1460 bytes of payload. That is why protocol efficiency is computed here as payload divided by total packet size, and why goodput, meaning throughput net of headers and retransmissions, is always the smallest of the three figures. Bulk TCP transfers on a tuned path typically land between 85 and 95 percent of line rate; 9000-byte jumbo frames push per-packet efficiency above 99 percent, while 64-byte packets fall below 50 percent. The bandwidth-delay product, bandwidth multiplied by round-trip time, imposes the second constraint. It is the volume of data that can be in flight at once, so a sender whose TCP window is smaller than the BDP stalls waiting for acknowledgements no matter how much capacity sits idle. A 1 Gbps path with 80 ms RTT has a BDP near 10 MB, far above the 64 KB ceiling of an unscaled TCP window. Loss compounds the problem: the Mathis approximation puts TCP throughput near the maximum segment size divided by the round-trip time and again by the square root of the loss probability, so even 0.1 percent loss on a long path is punishing. Treat these outputs as a first-order model. It assumes one steady flow, ignores slow start and queue buildup, and cannot know where in the path the throughput meter was placed.

Ethernet, published by Robert Metcalfe and David Boggs in 1976 from work begun at Xerox PARC in 1973, established the frame structure that still bounds these numbers, and the DIX specification issued by DEC, Intel and Xerox in 1980 fixed the 1500-byte maximum payload that remains the default MTU today. TCP itself descends from the 1974 design of Vint Cerf and Bob Kahn, split from IP and standardized as RFC 793 in 1981. Efficiency was not treated as a first-class operational concern until the NSFNET congestion collapses of 1986, after which Van Jacobson introduced slow start, congestion avoidance and improved round-trip estimation in his 1988 SIGCOMM paper. High bandwidth-delay paths exposed the next limit. The 16-bit TCP window field capped in-flight data at 65,535 bytes, which Jacobson, Bob Braden and Dave Borman addressed with window scaling and timestamps in RFC 1323 in 1992, revised as RFC 7323 in 2014; scaling lifts the ceiling to roughly 1 GB. Matthew Mathis and colleagues published the square-root loss model of TCP throughput in 1997, giving operators an analytic explanation for why long lossy paths underperform their headline capacity. Jumbo frames arrived from Alteon Networks in 1998 alongside gigabit Ethernet and remain non-standard but common inside data centers. Much of the practical tuning guidance that combines these ideas came out of research networking, notably the ESnet fasterdata program.