Ethernet Speed Calculator
The formula
What the ethernet goodput tells you
Why a gigabit link moves 940 Mbps and a 10G link 9.4: the interframe gap, preamble and header tax computed per frame size.
Calculation: Frame overhead = payload+20 IP+18 ETH+12 IFG+8 preamble; goodput = rate × payload share. Enter your inputs and every substitution is shown below the result.
Reading the result
Efficiency is a function of MTU alone — everything else on the link is variables you chose.
Rules of thumb: 1500 B MTU ≈ 94–96 % wire efficiency; 64-byte packet floods drop it below 60 % — the classic pps wall.
Limitations and best practice
Jumbo frames (9000) only pay if every switch and the endpoint NIC agree; one MTU mismatch drops the entire big-frame class.
This calculator gives an estimate based on standard formulas; it is not professional financial, medical, legal or engineering advice. Verify anything you plan to act on with a qualified professional and your own records.
Frequently asked questions
Do switches rate-limit by frame or bit?
Why 94 % TCP payload share?
Source & methodology
IEEE 802.3 frame format and interframe gap accounting.
Ethernet Speed: what this tool answers
You are here because you need a specific number, and you want to see how it was produced before you rely on it. There are plenty of pages about Ethernet Speed; almost none of them show the working. This one does: the formula, every input, a fully computed example, and a sensitivity analysis calculated live from this engine’s own defaults.
Most confusion about Ethernet Speed comes from mixing up the input you control with the input you merely observe. The formula treats them identically, but your decisions should not: one deserves measurement, the other deserves a defensible estimate.
Systems math in Technology & Computing has a peculiar property: it feels precise until an assumption breaks silently. Ethernet Speed is exact arithmetic over Frame overhead = payload+20 IP+18 ETH+12 IFG+8 preamble; goodput = rate × payload share — but only as truthful as the model. A wrong assumption about Link rate will not throw an error; it will just quietly produce the wrong 848 Mbps.
Nothing below is stock text pasted around a number: the worked example computes realistic goodput = 848 Mbps from this tool’s own defaults, and the sensitivity section ranks the inputs that move the result — TCP payload fraction of frame first, at ≈10.0 % of the headline for a ten-percent error either way in that input. Read the sections in order and you will be able to reproduce every figure by hand.
Inside the Ethernet Speed calculation: formula and every input
The engine implements a single stated model: Frame overhead = payload+20 IP+18 ETH+12 IFG+8 preamble; goodput = rate × payload share. There is no hidden coefficient and no login-gated precision — the formula printed is the formula executed, which is also what makes the result citable.
Link rate (example value 1 Gb/s) is a categorical input — the option you choose decides which numbers the formula uses. Enter it exactly as your document states it — quoted annual, monthly and effective rates are three different numbers.
MTU (bytes) (example value 1,520) is a plain measured quantity — the unit shown in the label is the unit the formula expects. Replace the example with the figure from your own records — the tool recomputes instantly and the printed steps follow your numbers.
TCP payload fraction of frame (%) (example value 88) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. Rates are the most mis-transcribed input on any page like this; copy it from the document rather than retyping from memory.
What each “Link rate” choice actually does: 1 Gb/s → 848 Mbps · 2.5 Gb/s → 2,119 Mbps · 10 Gb/s → 8,477 Mbps · 25 Gb/s → 21,191 Mbps · 100 Gb/s → 84,766 Mbps These figures are computed from this engine, not estimated — switch the dropdown above and you will land on exactly these numbers.
A fully worked Ethernet Speed example
Abstract formulas are hard to trust, so here is the complete substitution using the default inputs, written the way an examiner would want it. Starting figures: Link rate, MTU (bytes), TCP payload fraction of frame (%). The computed realistic goodput comes out at 848 Mbps, which the interpretation band labels “Overhead eating the pipe — raise MTU”.
- On-wire frame = 1,520 + 38 (L2/L3) + 20 (IFG+preamble) = 1,578 B
- MTU share = 1,520 ÷ 1,578 = 96.3 %
- × TCP/app share 88 % → 84.8 % of 1,000 Mbps
- Goodput = 848 Mbps (106.0 MB/s theoretical)
Wire efficiency — 84.8 %. If your inputs change, this is usually the first companion figure to move.
Per-frame overhead bytes — 58 B. This is the number experienced users quote when the headline alone would mislead.
File throughput equivalent — 104 Mbps. Read next to the headline, this is the figure that shows the shape of the trade-off.
Packet rate at this MTU — 79,214 pps. Compare it against the main result of 848 Mbps before drawing conclusions.
Overwrite any input above and every line of this example updates with it — the substitution is live, not a screenshot of somebody else’s numbers.
Scenario table: Ethernet Speed at ±10 % and ±20 % of the key input
Read this table as the practical error bar on the headline figure. It answers the question people actually have after seeing a single number: how wrong could this be if the main input is off by ten or twenty percent?
| TCP payload fraction of frame setting | Realistic goodput |
|---|---|
| 80 % of the example value | 678 Mbps |
| 90 % of the example value | 763 Mbps |
| example inputs | 848 Mbps |
| 110 % of the example value | 932 Mbps |
| 120 % of the example value | 1,017 Mbps |
The corridor runs from 678 Mbps to 1,017 Mbps across that band — which is the range worth planning inside rather than the single 848 Mbps point estimate. Reproduce it in the form above by editing TCP payload fraction of frame alone; the substitution steps will follow your figures exactly.
Where Ethernet Speed is fragile — and where it is not
This list was computed for this specific engine just now: each numeric input was nudged ±10 % while every other field held its example value, and the realistic goodput was recalculated from scratch. Read it as a map of where Ethernet Speed is fragile — drawn for the example inputs, which is the map you want when deciding what to measure carefully.
- TCP payload fraction of frame: ten percent up gives 932 Mbps, ten percent down gives 763 Mbps — ≈10.0 % of the realistic goodput either way
- Nudge MTU by ±10 % and Ethernet Speed lands between 844 Mbps and 850 Mbps (sensitivity ≈0.4 %)
TCP payload fraction of frame is the dominant lever here: ten percent either way moves the result by about 10.0 %, from 763 Mbps to 932 Mbps. That is where a careless figure does the most damage, so check it against a source, and treat MTU as the second priority (≈0.4 % per ten percent). The rest of the inputs earn only a rounding-error of attention, and that asymmetry is the practical payoff of measuring rather than asserting.
What an Ethernet Speed of 848 Mbps means in practice
Nobody acts on a bare figure — they act on a figure with a comparison attached. The default case lands in the “Overhead eating the pipe — raise MTU” band, and bands are deliberately wide because real situations overlap. Before treating the band as fact, note its width: ten percent either way on TCP payload fraction of frame already spans 763 Mbps to 932 Mbps. The practical reading rules: compare against your own history before comparing against other people; treat band boundaries as zones, not walls — one point on the wrong side of a threshold rarely changes a real outcome; and when a companion output contradicts the headline, believe the pair.
Related measures answer related questions, and the distinctions matter: Ethernet Speed is the quantity, Realistic goodput is this tool’s reading of it, and the decision that follows belongs to neither of them separately.
The errors that quietly break an Ethernet Speed figure
Jumbo frames (9000) only pay if every switch and the endpoint NIC agree; one MTU mismatch drops the entire big-frame class. This calculator gives an estimate based on standard formulas; it is not professional financial, medical, legal or engineering advice. Verify anything you plan to act on with a qualified professional and your own records.
Using stale inputs. Ethernet Speed is only as current as the numbers behind it — an estimate carried over from a previous season, rate table or report quietly biases every output. Re-measure the inputs first; that single habit fixes more bad Ethernet Speed figures than any formula change.
One mistake is specific to this engine: assuming every input matters equally. The computation above shows TCP payload fraction of frame dominating — a careful figure there beats false precision everywhere else.
Another is comparing across contexts: an Ethernet Speed computed with one set of conventions should never be lined up against a figure computed with another. Check the inputs behind both before ranking them.
Before you trust your Ethernet Speed: a short checklist
- State, in one sentence, which convention each rate, unit or period in the form is using.
- Compare the output against one published benchmark or a colleague’s independent estimate.
- Re-verify TCP payload fraction of frame against a source document — ten percent of error there moves the headline by ≈10.0 %.
- Re-run the calculation with a ±10 % stress on the two most sensitive inputs.
- Validate inputs against a live measurement, not datasheet peak figures.
- Confirm the answer against one independent method or published benchmark for Ethernet Speed.
A routine for decision-grade Ethernet Speed
The tool does the arithmetic; the routine below is what makes the arithmetic trustworthy. Five steps, a minute total — and afterwards you will know not just what the number is, but which assumption produced it.
Step 1 — one document, one pass. Open the statement, label or record that holds link rate, mtu (bytes), tcp payload fraction of frame (%) and transcribe straight into the form. Transcription from a single source removes the mismatch errors that appear when figures are assembled from three different places. Estimates improve most when the worst case is written down in ink.
Step 2 — baseline before exploration. Get one defensible Realistic goodput on screen before you start nudging numbers. Without a baseline, every variation looks interesting and none of them means anything. If the answer changes your behaviour, it deserves a second run with different assumptions.
Step 3 — change one input at a time. Nudge a single field by ten percent, watch the headline and its companions move, then undo it. Two or three fields will dominate — the sensitivity table above already ranks them for this engine. Re-running a number costs seconds; retracting a decision costs considerably more.
Step 4 — compute a corridor, not a point. Three runs — worst, likely, best — turn Ethernet Speed from a snapshot into a range. Plan against the pessimistic end and treat the optimistic end as the upside story. Repeating a calculation with the same numbers proves only that the arithmetic is reliable — which is worth knowing.
Step 5 — record the context, not just the number. Note today’s date and the inputs alongside the 848 Mbps output. Six months from now the context is what turns this figure into a trend. One decimal place more than your data supports is one decimal place of fiction.
From calculation to decision: where Ethernet Speed earns its keep
Technology & Computing arguments end at arithmetic or they do not end. Ethernet Speed is the arithmetic: 848 Mbps on the example inputs, reproducible by anyone who types the same numbers. If a result feels obviously right, that is the moment to check the inputs hardest.
Used properly this is a five-minute filter that saves weeks. Compute Ethernet Speed, reject what fails, and only then bring in the expensive analysis for the survivors. Write the assumptions in the same file as the result, and future arguments take minutes instead of meetings.
Re-running this page costs nothing and catches the slow drifts that never announce themselves. In Technology & Computing the expensive mistakes are rarely sudden; they are small changes in Link rate that nobody recalculated for a year. Write the assumptions in the same file as the result, and future arguments take minutes instead of meetings.
The questions that come up most about Ethernet Speed
What affects Ethernet Speed the most?
The short answer: TCP payload fraction of frame. The longer answer is the sensitivity table on this page, where every numeric input was probed by ten percent and the realistic goodput recalculated — TCP payload fraction of frame moved it furthest, by roughly 10.0 % (763 Mbps to 932 Mbps).
Which matters more: mtu or tcp payload fraction of frame?
TCP payload fraction of frame, by a factor of about 24.6. Concretely: ten percent on TCP payload fraction of frame is worth ≈10.0 % of Ethernet Speed, the same nudge on MTU only ≈0.4 %. That ranking is re-computed for each page from that page’s own defaults.
How much does the “Link rate” choice change the answer?
A great deal, on these inputs: Ethernet Speed comes out at 848 Mbps on the lowest option (“1 Gb/s”) and 84,766 Mbps on the highest (“100 Gb/s”). Each option is listed with its computed value so you can see what the choice is worth before you make it.
What is a typical Ethernet Speed?
There is no honest universal average for Ethernet Speed, but there is a reference point: the defaults on this page produce 848 Mbps (Overhead eating the pipe — raise MTU). Replace the inputs with your own and compare — that comparison is the useful meaning of “typical”.
How do I calculate Ethernet Speed by hand?
Frame overhead = payload+20 IP+18 ETH+12 IFG+8 preamble; goodput = rate × payload share is the entire method. Work the inputs in that order — On-wire frame = 1,520 + 38 (L2/L3) + 20 (IFG+preamble) = 1,578 B — and you will reach 848 Mbps on the default figures, the same number this tool prints.
What happens to Ethernet Speed if tcp payload fraction of frame changes by 10 %?
On these inputs a ±10 % change in tcp payload fraction of frame takes Ethernet Speed to 932 Mbps against the 848 Mbps example — around 10.0 % of the headline. The same test on every other field is in the sensitivity section.
Is the Ethernet Speed result of 848 Mbps good or bad?
The tool answers “what”, not “whether”: 848 Mbps carries the verdict “Overhead eating the pipe — raise MTU” for the default case, which is a starting interpretation rather than a verdict on your situation. Re-run with your own figures and compare the bands.
Is Ethernet Speed accurate?
The arithmetic is exact: Frame overhead = payload+20 IP+18 ETH+12 IFG+8 preamble; goodput = rate × payload share is evaluated with full floating-point precision and every substitution is printed in the worked example. What limits accuracy is input quality and the model’s assumptions, so treat the 848 Mbps result as the correct answer to the question you typed — and check the assumptions section before acting on it.
How often should I check Ethernet Speed?
Whenever an input changes by more than a few percent, and otherwise on the rhythm of your decisions — before a purchase, a review, a renewal. Ethernet Speed is a snapshot, not a subscription; stale snapshots are the most common silent error in Technology & Computing planning.
Do switches rate-limit by frame or bit?
Most silicon is wire-speed on bits but pps-limited on small frames — the last output is the number that breaks links under attack.
Why 94 % TCP payload share?
TCP/IP options, ACKs and retransmits occupy real air; 93–96 % is the normal application fraction at light loss.
Can this tool see the numbers I type?
It cannot. There is no submission step: the calculation happens in your browser and the result disappears when you close the page. Treat the fields above as a scratchpad rather than a form.
The vocabulary of Ethernet Speed
- Wire efficiency
- 84.8 % for the Ethernet Speed worked case; it sits next to the main result because it carries context the headline leaves out.
- Per-frame overhead bytes
- 58 B on the example inputs — a companion figure printed beside the headline of Ethernet Speed so that no result is read in isolation.
- File throughput equivalent
- 104 Mbps in the default Ethernet Speed calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
- Realistic goodput
- The primary output of this tool: 848 Mbps for the default inputs, computed exactly from Frame overhead = payload+20 IP+18 ETH+12 IFG+8 preamble; goodput = rate × payload share.
- Worked example
- Every substitution in order, from the example inputs to 848 Mbps — the audit trail for the headline figure.
- Verdict band
- The plain-language label — here “Overhead eating the pipe — raise MTU” — mapping the computed figure onto experience-based ranges for Technology & Computing.
- Sensitivity (±10 %)
- How far the Ethernet Speed moves when a single input is nudged ten percent either way; the ranked list on this page is computed live from this engine.
Where the Ethernet Speed model comes from
There is no black box on this page — the engine evaluates Frame overhead = payload+20 IP+18 ETH+12 IFG+8 preamble; goodput = rate × payload share. Source of record: IEEE 802.3 frame format and interframe gap accounting. Specialist software layers extra coefficients on top of the same algebra; none are hidden here, and that transparency is what makes a disagreement traceable to a specific input instead of a black box.
This page is an estimation aid, not professional advice. The design rule is simple: two people entering identical figures must get identical answers. The design constraint was set by usefulness rather than by comfort: an estimate you can interrogate beats an answer you have to trust.
Turning this Ethernet Speed into a decision
Re-run the calculation with your own figures, stress the two most sensitive inputs by ±10 %, and only then act on the result.
The audience here is people who need one trustworthy number before their next decision. Everything you need to defend the result — formula, substitution, sensitivity, source — is printed above, so the only remaining variable is the honesty of your inputs.