Line Rate Throughput Calculator

September 1, 2026

HomeServerBlog Ethernet wire-rate planner

Line Rate Throughput Calculator

Estimate Ethernet payload throughput, packets per second, framing overhead, and efficiency from link speed, frame size, VLAN tags, FCS handling, protocol headers, duplex mode, utilization, stream count, and useful payload size.

1Ethernet presets

2Line-rate inputs

Enter the nominal physical line rate for one direction.
Use decimal network rates: 1 Gbps = 1,000,000,000 bps.
Bytes inside Ethernet after the MAC header, before FCS.
Application or test payload carried in each packet.
IP, TCP, UDP, tunnel, storage, or test header bytes inside the MTU.
VLAN tags add bytes to the Ethernet frame on tagged links.
Standard Ethernet line-rate math uses 8 bytes.
Standard Ethernet reserves 12 byte-times between frames.
Wire-rate sizing normally includes FCS; captures often hide it.
Only used when FCS mode is set to custom.
Full duplex doubles aggregate traffic across both directions.
Apply headroom for host limits, shaping, testing, or safety margin.
Equal payload streams sharing the calculated aggregate rate.
Use 14 for Ethernet II before VLAN tags.
Optional target for headroom status.
Compare modeled payload throughput or million packets per second against a lab goal.
Payload Throughput 0 Mbps useful payload after utilization One direction
Packets Per Second 0 frames per second on the link aggregate pps
Overhead Rate 0 Mbps non-payload bits at selected load headers, FCS, preamble, IFG, padding
Wire Efficiency 0% payload bytes divided by wire bytes per frame payload share

Calculation breakdown

Fit and stream status

Ready.

3Current frame details

0 BWire bytes

Frame plus preamble, IFG, VLAN tags, and FCS mode.

0 BMAC frame

Ethernet header, tags, payload field, and FCS when counted.

0 BMax useful payload

Frame payload ceiling minus protocol overhead.

0 MbpsPer stream

Aggregate payload divided across the stream count.

4Protocol comparison grid

5Ethernet overhead tables

Ethernet componentBytesCounts in capture?Line-rate note
Preamble plus start frame delimiter8Usually noConsumes wire time before every Ethernet frame.
Inter-frame gap12NoIdle byte-times that still reduce maximum pps.
Destination and source MAC12YesPart of the 14 byte Ethernet II header.
EtherType or length field2YesCompletes the normal 14 byte Ethernet header.
802.1Q VLAN tag4 eachUsually yesAdds 4 bytes per tag on a trunk or tagged access frame.
Frame check sequence4Often noPresent on the wire even when packet captures hide it.
Common frame caseWire bytes1G maximum pps10G maximum pps
Minimum untagged Ethernet frame84 B1,488,09514,880,952
Minimum single-tag VLAN frame88 B1,420,45514,204,545
1500 MTU, untagged, FCS counted1538 B81,274812,744
1500 MTU, one VLAN tag1542 B81,063810,635
9000 MTU, untagged jumbo9038 B13,830138,304
9000 MTU, one VLAN tag9042 B13,824138,243
Protocol profileOverhead inside MTUTypical payload at 1500Use in home labs
IPv4 TCP40 B1460 BNAS, HTTP, SMB, backups, and most tests.
IPv4 UDP28 B1472 Biperf3 UDP, DNS, RTP, telemetry, and tunnels.
IPv6 TCP60 B1440 BDual-stack services and routed IPv6 labs.
PPPoE IPv4 TCP48 B1452 BFiber or DSL WAN where PPPoE reduces MTU.
WireGuard IPv4 TCP100 B1400 BRemote home server VPN and site-to-site links.
VXLAN IPv4 TCP90 B1410 BVirtualization overlays and tenant networks.
Planning scenarioFrame size to testOverhead focusPractical note
Firewall small-packet forwarding64 to 128 B framesPacket rateCPU, ASIC, NAT, and rule count usually matter more than Mbps.
NAS or backup throughput1500 or 9000 MTUPayload efficiencyJumbo frames reduce pps only when every hop supports them.
VLAN trunk uplink1504 plus tagsTag overheadOne or two tags slightly reduce payload rate and pps ceiling.
VPN over Ethernet1200 to 1420 payloadTunnel headersCompare encrypted goodput with CPU and NIC offload limits.
Full duplex storage replication1500 to 9000 MTUAggregate directionFull duplex can receive and transmit line rate at the same time.

6Line-rate calculation tips

Count the invisible bytes. Preamble, start frame delimiter, FCS, and inter-frame gap may not appear in host packet captures, but they consume wire time and set the real pps ceiling.
Use pps for small-packet limits. A firewall can pass a large Mbps number with jumbo frames and still struggle with 64-byte packets, NAT, ACLs, VPN encryption, or interrupt load.
This calculator is a planning model for Ethernet links. Real measurements can be lower because of NIC offloads, switch silicon limits, flow control, congestion, disk I/O, CPU affinity, interrupt moderation, TCP window size, and test-tool behavior.

The trick with line rates is that you can have a pipe filled with either rock or water, they may appear equally full on the outside but one are full of something else. Gigabit links sound impressive until you want to shove a million tiny packets down them. The calculator above will do the maths for you. But knowing how and why those numbers shift is more important then the tool itself.

A frame on Ethernet isn’t simply a stream of valuable data bits. It’s a frame carrying baggage. It includes the preamble and start frame delimiter. It also contains destination and source MAC addresses and frame check sequence. And don’t forget about the inter-frame gap; those dozen idle byte-times between each frame that allow for receiver resets and collision avoidance. These invisible bytes is often hidden in packet captures. The result? Your lab tests may indicate 90 percent efficiency when in reality the wire’s been choked by overhead. Count what you’re not seeing.

Why Small Packets Slow Down Your Network

The lever you pull is frame size. Big frames such as jumbo packets carries more payload per header which lowers the overhead-to-useful-data ratio. Small frames do just the opposite. A sixty-four byte packet isn’t much; it is mostly overhead. The wire sends your files along with headers and gaps, but with small frames, it spend most of its time transmitting those headers and gaps rather than your actual data. Your switch or firewall may hit its packets per second limit on small frames; your throughput will drop to zero though your Mbps use may look low.

Then there’s VLAN tags on top of that. A single eight-zero-two-dot-one-Q tag is just four bytes. Those four bytes take away from your MTU. Yeah, you may think you’ve got fifteen hundred bytes to play with as payload, but there’s the tag. It reduces it. Double tagging in QinQ reduces it even more. It is a small thing, but it matters if you are trying to squeeze every ounce of bandwidth out of an uplink trunk.

This is made worse by protocol overhead. Ethernet adds fourteen bytes, IP adds another twenty, TCP adds another twenty. And that’s before you’ve even sent a single byte of your file. Layer VPNs such as VXLAN or WireGuard on top and now you’re tunneling packets within packets. Every tunnel header is pure cost. The wire frame remains the same size or even grows, but your effective payload shrinks. That’s why encrypted tunnels can feel slow relative to raw Ethernet. The bandwidth is there; it’s just that payload capacity are gone.

The math changes when you factor in duplex: full duplex means being able to transmit and receive simultaneously at line rate. At a gigabit/second, you’re sending and receiving at the same time. Half duplex shares that medium. Because total capacity is wildly different across these two types of operation, the calculator takes it into account. Remember: sending and receiving both ways is only a possibility; one direction at a time is what actualy happens.

Safety valves are usage targets. If you push a link to a hundred percent of capacity, you’re begging for congestion. Windows will burst; packets will get lost and retransmitted; latency will spike. A use target of ninety-five percent gives room for interrupts to be handled and for flow control. Networks should breathe. When there’s a burst, they need somewhere to expand in.

That’s where the page’s reference table comes into play. For typical cases, it spells it all out: As frame size increases, the packets per second (pps) ceilings decreases. With minimal-size frames, a one-Gigabit link can process more than a million packets per second, while full-sized jumbo frames will limit that to just under eighty-one thousand. That’s a tenfold difference in the packet processing load! When switches and CPUs reaches their interrupt-per-second limit, it doesn’t matter if you still have plenty of bandwidth; the hardware has reached its throughput limit, and no longer cares.

The math isn’t hard; it’s its interpretation that makes the plan succeed or fail. Packets per second is what matters for smaller frames. Payload efficiency matters when you’re trying to send big files. Don’t lose yourself in the raw Mbps numbers. The pipe might be wide enough for a truck, but if it’s stuffed with gravel, you should of known you ain’t going nowhere. Leave yourself some breathing room, respect the overhead, and keep frame sizes honest.

Line Rate Throughput Calculator

Related posts

Leave a Comment