How Much Usable Throughput Does Protocol Overhead Take From a Home NAS Link?

Protocol overhead usually removes a few percent of a well-filled wired NAS link before SMB and application behavior are considered. With a standard 1500-byte MTU, TCP over IPv4 can carry 1460 bytes of application payload inside each IP packet, while Ethernet framing, the preamble, and the inter-frame gap consume additional wire time.

That arithmetic is only a theoretical efficiency ceiling for large clean transfers. Small files, partial packets, acknowledgements, SMB messages, encryption, latency, retransmissions, storage waits, and client behavior can reduce real goodput much further.

What Is the Difference Between Line Rate and Goodput?

Line rate describes how quickly the interface signals bits, while goodput counts only delivered application data. Headers, acknowledgements, retransmissions, and control messages are real traffic but not bytes added to the completed user file.

A 1GbE port therefore cannot deliver 125 MB/s of file payload indefinitely. That number converts one billion signaled bits per second into bytes before subtracting any framing or protocol work.

Goodput should be measured at the application after the transfer completes. Interface counters measure broader traffic and can include retries or data that the application has not yet committed.

How Much Do Ethernet, IP, and TCP Headers Remove?

For standard TCP over IPv4 without options, TCP and IP headers reduce payload efficiency. The 40-byte TCP/IP cost is about 2.7% of the IP MTU before Ethernet wire overhead is included.

At Ethernet wire level, a full-sized frame also uses a 14-byte header, 4-byte FCS, 8-byte preamble and start delimiter, and a 12-byte inter-frame gap. A 1460-byte TCP payload can therefore occupy roughly 1538 byte-times on a simple untagged Ethernet path.

That ratio is about 94.9% payload efficiency. The approximate ceiling is therefore around 949 Mbps on 1GbE, 2.37 Gbps on 2.5GbE, and 9.49 Gbps on 10GbE before SMB, storage, acknowledgements, and implementation limits.

Why Does Payload Size Change the Percentage Lost?

Most headers have a fixed size per packet, so larger payloads amortize fixed frame overhead. A full 1500-byte packet is much more efficient than a packet carrying only a few hundred bytes.

Small synchronous requests can therefore spend a larger share of their wire time on framing, requests, responses, and acknowledgements. File count and application round trips matter even when total payload bytes are modest.

Jumbo frames improve the ratio further, but the maximum mathematical gain is smaller than many storage bottlenecks. They also require consistent MTU support across every device and virtual layer on the path.

What Additional Work Does SMB Add Above TCP?

SMB adds message headers, request and response semantics, credits, authentication state, signing or encryption, and file-operation round trips. small files repeat application and protocol setup.

For a large pipelined read or write, SMB overhead can be amortized across substantial payloads and several outstanding requests. For tiny files and metadata operations, open, query, permission, close, and directory messages become a larger share of elapsed time.

Signing and encryption also consume CPU and memory bandwidth without necessarily adding a large number of wire bytes. Protocol overhead therefore includes processing cost, not only header size.

Why Can Real Transfers Lose More Than Header Arithmetic Predicts?

Header arithmetic assumes full payloads, no loss, adequate windows, and endpoints that process packets fast enough. latency and loss create costs beyond header bytes.

Packet loss adds retransmissions and congestion-control reductions. Latency limits how quickly the sender receives feedback. Small TCP windows, underfilled queues, storage pauses, or one busy CPU core can leave the wire idle even though theoretical framing efficiency is high.

A file manager may also perform buffered single-stream copies, while a benchmark uses several workers or memory buffers. The difference between those tools is application behavior, not protocol headers alone.

How Should a Home NAS Estimate Practical Throughput?

jumbo frames reduce overhead only on a validated path. Start with the standard-MTU wire-efficiency ceiling, then subtract measured endpoint and workload limits rather than applying one universal percentage.

Use a network-only test to establish TCP goodput, then run a large-file NAS copy, a small-file workload, and the actual application. Record line rate, application bytes, CPU, storage latency, retransmissions, packet size, and whether signing or encryption is enabled.

A planning allowance such as 10–15% below link rate can be reasonable for scheduling large transfers, but it is not a protocol constant. A healthy tuned LAN may approach the wire-efficiency ceiling, while small files or constrained endpoints can lose far more.

FAQ

What is the theoretical TCP payload ceiling on 1GbE?

With full 1500-byte TCP/IPv4 packets and simple Ethernet wire accounting, it is roughly 949 Mbps before SMB and endpoint limits.

Does SMB always cost 10 or 15 percent?

No. Its impact depends on request size, file count, signing, encryption, concurrency, CPU, storage, and client implementation.

Will jumbo frames recover all protocol overhead?

No. They reduce per-packet framing and processing frequency but do not remove SMB operations, acknowledgements, storage waits, or application behavior.

Why can a 10GbE NAS copy stay below 9.49 Gbps?

The storage array, client disk, CPU, PCIe path, SMB settings, queue depth, packet loss, and copy tool may become limiting before wire efficiency.

Final Takeaway

Protocol overhead turns line rate into lower goodput through fixed Ethernet, IP, TCP, and SMB work. Full standard frames can retain roughly 95% of wire rate as TCP payload, but real NAS transfers also pay for file operations, security, feedback, loss, latency, and endpoint stalls. Calculate the header ceiling first, then measure the workload-specific gap.