Corresponding this topic:
The maximum segment size (which does not include the TCP or IP
headers) is typically negotiated between the layers to the size of the
MTU minus the headers size. For Ethernet MTU is usually configured at
1500 bytes. The TCP header is 160 bits, or 20 bytes. The fixed part of
the IPv4 header is 160 bits, or 20 bytes as well. … . Thus:
- for HTTP over TCP/IPv4
overhead = TCP + IP = 40 bytes
payload = 1500 – 40 = 1460 bytes
overhead % = 2% (40 * 100 / 1460)
Here's 100 Mbit and 1Gbit iperf results in TCP mode with default Debian distros:
[ 5] local 10.0.51.1 port 5001 connected with 10.0.51.20 port 45009
[ 5] 0.0-10.0 sec 112 MBytes 94.1 Mbits/sec
[ 4] local 10.0.51.1 port 5001 connected with 10.0.51.94 port 35065
[ 4] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec
I can lower it to almost 2% overhead by raising MTU to 9000 :
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.14 GBytes 982 Mbits/sec
But shouldn't it be even less?
overhead = TCP + IP = 40 bytes
payload = 9000 - 40 = 8960 bytes
overhead % = 0.4% (40 * 100 / 8960)
Why actual "bandwidth loss" is notably greater than the theoretical?
If formula missing something valuable?
Best Answer
Ethernet packets 1.5k
1500 - 20 B (IPv4) - 20 B (TCP+checksum) = 1460 B DATA (and 40 B Overhead)
Add 40 B + 14 B (Ethernet) + 4 B (FCS) + 12 B (Interframe gap) + 8 B (preamble) = 78 B Overhead
78 / 1460 * 100 = 5.34% overhead
1460 / ( 1460 + 78) * 100 = 94.93% Throughput/Goodput
1,000,000,000(1Gbit) * 94.93% = 949Mbit/s(0.949Gbit/s)
you measured 941Mbit/s that gives (949 - 941) / 949 * 100 = 0.84 % error between theoretical and actual.
Jumbo packets 9k - Theoretical max
1,000,000,000(1Gbit) * 99.14% = 991Mbit/s(0.99Gbit/s)