Throughput Calculator
The formula
What the window-limited throughput tells you
The throughput a link actually delivers given TCP window size, latency and stream count — why a gigabit pipe can move data at megabit speed.
Calculation: Per-flow max = window ÷ RTT; total = min(link, streams × window/RTT); BDP = bandwidth × RTT. Enter your inputs and every substitution is shown below the result.
Reading the result
Raise the window or add streams until their product clears the BDP; past that point the link is the limit and tuning stops paying.
Rules of thumb: Default Linux windows saturate 1 Gbps/40 ms with 4–8 streams; a single stream needs a 5 MB window.
Limitations and best practice
Windows scale only if both ends advertise them — an old appliance or a middlebox clamping at 64 KB silently caps every flow.
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
Is UDP faster?
What window do I need?
Source & methodology
TCP congestion-window model per RFC 5681 and the bandwidth-delay product formulation of Clark (1988).
Throughput: 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. Throughput is the kind of number people argue about from memory. This page ends that argument with arithmetic you can watch happen: enter your figures, get Achievable throughput in real time, and see every substitution printed below.
The number itself is the easy part. What takes judgement is knowing which inputs are facts in your situation and which are guesses wearing a decimal point — a distinction this page makes explicit for every field above.
That makes documentation a feature. The steps block above exists so that the next engineer to read this page can verify not just the result but the reasoning — the difference between a number that gets acted on and one that gets argued with.
Nothing below is stock text pasted around a number: the worked example computes achievable throughput = 51.2 Mbps from this tool’s own defaults, and the sensitivity section ranks the inputs that move the result — RTT first, at ≈11.1 % of the headline for a ten-percent error either way in that input. Work down the page and by the end you could re-derive the result in a spreadsheet from memory.
Every input in Throughput, and what it does to the answer
Here is the complete model this tool runs — Per-flow max = window ÷ RTT; total = min(link, streams × window/RTT); BDP = bandwidth × RTT — with each input explained below. If a competitor’s page gives you a different answer from the same inputs, this is the text that settles which of you is right.
Link bandwidth (Mbps) (example value 980) is a measured number in the unit named by the label; the formula does not convert for you. The example value is there to demonstrate the mechanics, not to describe your situation — overwrite it.
RTT (ms) (example value 41) is a numeric input whose unit is fixed by the label; a wrong unit is a wrong answer wearing a plausible disguise. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.
TCP window per stream (KB) (example value 64) is a measured number in the unit named by the label; the formula does not convert for you. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.
Parallel streams (example value 4) is a quantity rather than a category — precision here is cheap and worth having. The example value is there to demonstrate the mechanics, not to describe your situation — overwrite it.
Throughput on the example inputs: the complete substitution
The tool prints its own working; this is the same arithmetic on the example values, reproduced so you can follow it by hand. Starting figures: Link bandwidth (Mbps), RTT (ms), TCP window per stream (KB), Parallel streams. The endpoint of that chain is 51.2 Mbps of achievable throughput, sitting in the “Heavily window-starved” band.
- BDP = 980 Mbps × 41 ms = 4,905 KB in flight
- One 64 KB window over 41 ms = 12.8 Mbps
- 4 streams = 51 Mbps demand vs 980 Mbps link
- Bottleneck gives 51.2 Mbps
Per-flow ceiling — 12.8 Mbps. Read next to the headline, this is the figure that shows the shape of the trade-off.
Bandwidth-delay product — 4,905 KB. Read next to the headline, this is the figure that shows the shape of the trade-off.
Streams needed to saturate — 77. Compare it against the main result of 51.2 Mbps before drawing conclusions.
Time for a 10 GB file — 1.6 s. This is the number experienced users quote when the headline alone would mislead.
Keep this worked example open while you enter your own figures: matching the shape of the substitution is the fastest way to spot a unit or convention mistake.
The Throughput corridor: your result across a realistic band
The honest version of any estimate is a corridor, and this one is cheap to produce: Throughput was recomputed at 5 points along the dominant input, with every other field left untouched.
| RTT setting | Achievable throughput |
|---|---|
| 80 % of the example value | 63.9 Mbps |
| 90 % of the example value | 56.8 Mbps |
| example inputs | 51.2 Mbps |
| 110 % of the example value | 46.5 Mbps |
| 120 % of the example value | 42.6 Mbps |
The corridor runs from 42.6 Mbps to 63.9 Mbps across that band — which is the range worth planning inside rather than the single 51.2 Mbps point estimate. Reproduce it in the form above by editing RTT alone; the substitution steps will follow your figures exactly.
The levers behind Throughput, ranked by effect
Nobody should have to guess which input matters. The engine was re-run once per field below — ten percent up, ten percent down, everything else frozen — and the results ranked by how far they moved the achievable throughput. It is the fastest honest answer to “what matters most in Throughput?” — and it is specific to these defaults, because sensitivity moves with the starting point.
- RTT +10 % → Throughput = 46.5 Mbps · −10 % → 56.8 Mbps (the achievable throughput shifts ≈11.1 %)
- Parallel streams +10 % → Throughput = 56.3 Mbps · −10 % → 46.0 Mbps (the achievable throughput shifts ≈10.0 %)
- Nudge TCP window per stream by ±10 % and Throughput lands between 46.0 Mbps and 56.3 Mbps (sensitivity ≈10.0 %)
RTT is the dominant lever here: ten percent either way moves the result by about 11.1 %, from 46.5 Mbps to 56.8 Mbps. That is where a careless figure does the most damage, so check it against a source, and treat Parallel streams as the second priority (≈10.0 % per ten percent). The remaining fields can sit at safe defaults without materially changing the answer — knowing which is which is what separates a careful calculation from an anxious one.
What a Throughput of 51.2 Mbps means in practice
A number on its own is trivia; a number against a range is intelligence. On the example inputs the band reads “Heavily window-starved”; your own figures place you on a different rung of the same ladder. Before treating the band as fact, note its width: ten percent either way on RTT already spans 46.5 Mbps to 56.8 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.
Placing this figure in context: calculators of this kind differ less in arithmetic than in what they choose to ignore. This one keeps Link bandwidth (Mbps) explicit so that the omissions are visible rather than hidden in a preset.
Common mistakes with Throughput (and the fix)
Windows scale only if both ends advertise them — an old appliance or a middlebox clamping at 64 KB silently caps every flow. 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.
Stopping at the first plausible answer. If the result surprises you, the productive question is which input would have to be wrong for the surprise to disappear — then go check that input.
Attention is also misallocated between fields. Having measured this engine, we can say where it belongs: RTT first, everything else second.
A final trap is presentation: reporting Throughput to more decimal places than the inputs support. The tool prints what the arithmetic gives; you should quote only what your least precise field justifies.
Throughput verification checklist
- Confirm the example values are plausible for your own situation before replacing them.
- Note the date and the inputs beside the number so the figure can be audited later.
- Check RTT before anything else: it is the measured dominant input, ≈11.1 % of Throughput per ten percent.
- Compare the result with one independent method or published benchmark.
- Validate inputs against a live measurement, not datasheet peak figures.
- Repeat the ±10 % test on the inputs that matter and see whether the decision — not just the number — still holds.
A routine for decision-grade Throughput
Using a calculator well sounds trivial, but the difference between a decision-grade figure and a throwaway one lives entirely in the routine. The routine for Throughput takes a minute to learn and applies to every input above.
Step 1 — gather before you type. Throughput depends on link bandwidth (mbps), rtt (ms), tcp window per stream (kb), parallel streams. Collect them from a source document — a statement, a report, an invoice, a log — rather than from memory, because recalled inputs are the single largest cause of wrong results. Note the assumption you are least sure about; that is where the real risk lives.
Step 2 — start from the case you can defend. Enter pessimistic-but-honest figures first; the optimistic run is a ceiling, not a plan. A conclusion that holds on conservative inputs holds everywhere. 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. Note the assumption you are least sure about; that is where the real risk lives.
Step 4 — compute a corridor, not a point. Three runs — worst, likely, best — turn Throughput 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 — write the one-line memo. “Achievable throughput = 51.2 Mbps on this date, from these inputs.” That line is the entire deliverable; everything else on this page is how you earned the right to write it. Write the assumptions in the same file as the result, and future arguments take minutes instead of meetings.
From calculation to decision: where Throughput earns its keep
Numbers earn their keep in conversations, and Throughput is no exception. In Technology & Computing discussions around Networks & Storage, this figure decides whether an option stays on the table: it converts an opinionated debate into an arithmetic one, and arithmetic is the only referee both sides accept. Estimates improve most when the worst case is written down in ink.
The companion outputs — Per-flow ceiling and Bandwidth-delay product — exist for the second stage of that screen: the headline sizes the prize, while the companions describe the trade-off you are accepting to get it. 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 bandwidth (Mbps) that nobody recalculated for a year. Compare the calculation to the rough guess you arrived with, and ask why they differ.
The questions that come up most about Throughput
What affects Throughput the most?
Throughput is driven above all by RTT. Perturbing only that field by ten percent either way produced 46.5 Mbps against the 51.2 Mbps baseline — a ≈11.1 % response, while Parallel streams manages ≈10.0 %.
Which matters more: parallel streams or rtt?
For Throughput, RTT wins the head-to-head (≈11.1 % against ≈10.0 % per ten-percent change). Knowing which input dominates is the difference between careful work and merely slow work.
What is a typical Throughput?
There is no honest universal average for Throughput, but there is a reference point: the defaults on this page produce 51.2 Mbps (Heavily window-starved). Replace the inputs with your own and compare — that comparison is the useful meaning of “typical”.
How do I calculate Throughput by hand?
Use the stated model — Per-flow max = window ÷ RTT; total = min(link, streams × window/RTT); BDP = bandwidth × RTT — and substitute in the order the tool prints (it starts from BDP = 980 Mbps × 41 ms = 4,905 KB in flight). On the example inputs the hand route lands on 51.2 Mbps, exactly what the calculator shows. A spreadsheet reproduces it in two or three cells; doing it once by hand is what makes the automated answer trustworthy.
What happens to Throughput if rtt changes by 10 %?
The engine was re-run with that field moved by ten percent while everything else stayed fixed: the achievable throughput goes across 46.5 Mbps to 56.8 Mbps, a swing of roughly 11.1 % around the 51.2 Mbps baseline. That ratio is the practical definition of how much this input matters.
Is the Throughput result of 51.2 Mbps good or bad?
The tool answers “what”, not “whether”: 51.2 Mbps carries the verdict “Heavily window-starved” 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.
What affects Throughput the most?
Sensitivity depends on where you start, but the inputs Link bandwidth (Mbps) and RTT (ms) typically move Throughput further than the rest because they enter the formula multiplicatively. If you can only measure two things well, measure those and hold the others at conservative defaults.
How often should I check Throughput?
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. Throughput is a snapshot, not a subscription; stale snapshots are the most common silent error in Technology & Computing planning.
Is UDP faster?
UDP skips window ramp but without congestion control it just floods the buffer and starts dropping — for bulk transfer TCP with tuning usually wins.
What window do I need?
Window ≥ BDP: multiply your Mbps by RTT ms and divide by 8000 to get KB per flow.
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 Throughput
- Per-flow ceiling
- 12.8 Mbps in the default Throughput calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
- Bandwidth-delay product
- 4,905 KB in the default Throughput calculation — one of the secondary figures an experienced reader checks before trusting the primary number.
- Streams needed to saturate
- 77 for the Throughput worked case; it sits next to the main result because it carries context the headline leaves out.
- Achievable throughput
- The primary output of this tool: 51.2 Mbps for the default inputs, computed exactly from Per-flow max = window ÷ RTT; total = min(link, streams × window/RTT); BDP = bandwidth × RTT.
- Worked example
- The calculation written out in full so that nothing on this page has to be taken on trust.
- Verdict band
- The plain-language label — here “Heavily window-starved” — mapping the computed figure onto experience-based ranges for Technology & Computing.
- Sensitivity (±10 %)
- How far the Throughput moves when a single input is nudged ten percent either way; the ranked list on this page is computed live from this engine.
The provenance of this Throughput calculation
The model is published arithmetic implemented exactly as written: Per-flow max = window ÷ RTT; total = min(link, streams × window/RTT); BDP = bandwidth × RTT. Source of record: TCP congestion-window model per RFC 5681 and the bandwidth-delay product formulation of Clark (1988). Any other implementation of this model should return the same figure for the same inputs. If one does not, the difference is in its assumptions — which this page prints and that one probably does not.
Nothing here replaces a qualified professional, and nothing here is approximate either — the arithmetic is exact, and the honesty is in the inputs you supply. The design constraint was set by usefulness rather than by comfort: an estimate you can interrogate beats an answer you have to trust.
What to do with your Throughput next
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.