Channel Bonding Calculator
The formula
What the bonded throughput tells you
Aggregating unlike links honestly: the pooled pipe for many flows, and the far smaller number a single TCP stream will ever see.
Calculation: Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest. Enter your inputs and every substitution is shown below the result.
Reading the result
Bonding is a many-flow technology — videoconferences and backups love it; your one big download never sees the aggregate.
Rules of thumb: Load-balancer marketing: “2×100 Mbps = 200” — the survivable and single-stream columns are the real design numbers.
Limitations and best practice
Mixed latency between members causes packet reordering that hurts TCP; use per-flow (not round-robin) schedulers.
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
Does bonding raise upload too?
Can I bond fibre + 5G + DSL?
Source & methodology
Standard multi-WAN/bonding practice (packetization overhead and per-flow scheduler limits).
Channel Bonding explained: formula, worked example and honest limits
You are here because you need a specific number, and you want to see how it was produced before you rely on it. Channel Bonding 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 Bonded aggregate in real time, and see every substitution printed below.
It helps to separate the mechanics from the interpretation. The mechanics are fixed: Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest. Anyone, anywhere, entering the same inputs will get the same 172.9 Mbps. The interpretation is where experience counts: whether 172.9 Mbps is good, normal or alarming depends on comparisons covered below, and that is the part most articles about Channel Bonding never explain.
People rarely disagree about arithmetic; they disagree about assumptions that were never written down. Printing the substitution and the sensitivity ranking removes that category of disagreement for Channel Bonding.
Every figure in the prose is generated by the engine rather than written beside it — the worked example resolves to bonded aggregate = 172.9 Mbps on the default inputs, and the sensitivity section ranks the inputs that move the result — Link 1 first, at ≈5.4 % of the headline for a ten-percent error either way in that input — which is the thread the rest of this guide pulls on.
Every input in Channel Bonding, and what it does to the answer
One formula, published in full: Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest. Anything you can read, you can reproduce in a spreadsheet, and that reproducibility is the whole point of printing it rather than hiding it behind a button.
Member links (example value 2 links) is a choice rather than a quantity — pick the option that matches your situation, because the calculation path branches here. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.
Link 1 (Mbps) (example value 98) is a quantity rather than a category — precision here is cheap and worth having. This input feeds the formula directly; a defensible figure here is worth more than false precision anywhere else.
Link 2 (Mbps) (example value 84) is a measured number in the unit named by the label; the formula does not convert for you. Replace the example with the figure from your own records — the tool recomputes instantly and the printed steps follow your numbers.
Link 3 (Mbps) (example value 50) 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.
Link 4 (Mbps) (example value 53) is a plain measured quantity — the unit shown in the label is the unit the formula expects. This input feeds the formula directly; a defensible figure here is worth more than false precision anywhere else.
What each “Member links” choice actually does: 2 links → 172.9 Mbps · 3 links → 220.4 Mbps · 4 links → 270.8 Mbps That table is the honest answer to “does this option matter”, re-derived from the formula rather than hard-coded into page copy.
The default Channel Bonding calculation, written out in full
Rather than describe the calculation, here it is end to end — every substitution in order, starting from the inputs above. Starting figures: Member links, Link 1 (Mbps), Link 2 (Mbps), Link 3 (Mbps). Run to the end, the bonded aggregate resolves to 172.9 Mbps — Modest pooling gain on the bands this tool uses.
- Members: 98 + 84 Mbps
- Aggregate × 0.95 packetization = 172.9
- Per-flow: scheduler can rarely beat the fastest member by more than ~half of the others → 140.0
- Worst-case failover still delivers 93.1
Realistic single-stream gain — 140.0 Mbps. This is the number experienced users quote when the headline alone would mislead.
Survivable capacity if worst link dies — 93.1 Mbps. Read next to the headline, this is the figure that shows the shape of the trade-off.
Weakest link (failover cost) — 84.0 Mbps. Read next to the headline, this is the figure that shows the shape of the trade-off.
Overhead tax (5 %) — 9.1 Mbps. Compare it against the main result of 172.9 Mbps before drawing conclusions.
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.
How far Channel Bonding can reasonably move
The honest version of any estimate is a corridor, and this one is cheap to produce: Channel Bonding was recomputed at 5 points along the dominant input, with every other field left untouched.
| Link 1 setting | Bonded aggregate |
|---|---|
| 80 % of the example value | 154.3 Mbps |
| 90 % of the example value | 163.6 Mbps |
| example inputs | 172.9 Mbps |
| 110 % of the example value | 182.2 Mbps |
| 120 % of the example value | 191.5 Mbps |
That spread — 154.3 Mbps at the low end, 191.5 Mbps at the high — is what a careful read of Channel Bonding looks like: a band you can state out loud, with the reason for each edge. Reproduce it in the form above by editing Link 1 alone; the substitution steps will follow your figures exactly.
Where Channel Bonding 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 bonded aggregate was recalculated from scratch. For Channel Bonding the ranking is measured rather than guessed, and it belongs to these defaults: shift the starting point and the order can shift with it.
- Link 1 +10 % → Channel Bonding = 182.2 Mbps · −10 % → 163.6 Mbps (the bonded aggregate shifts ≈5.4 %)
- Nudge Link 2 by ±10 % and Channel Bonding lands between 164.9 Mbps and 180.9 Mbps (sensitivity ≈4.6 %)
Link 1 is the dominant lever here: ten percent either way moves the result by about 5.4 %, from 163.6 Mbps to 182.2 Mbps. That is where a careless figure does the most damage, so check it against a source, and treat Link 2 as the second priority (≈4.6 % 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.
Reading the result: bands, zones and thresholds
The value above only becomes useful the moment you know what it is being measured against. The default case lands in the “Modest pooling gain” band, and bands are deliberately wide because real situations overlap. How much of that band is luck? On Link 1 alone ten percent either way covers 163.6 Mbps to 182.2 Mbps. The practical reading rules: read the band as a starting hypothesis, then test it: change the two dominant inputs by ten percent and see whether the verdict survives. Verdicts that survive stress are the ones worth acting on.
The comparison worth making is not with somebody else’s Channel Bonding but with the version of your own situation measured last quarter — same formula, same conventions, different inputs.
Why Channel Bonding results go wrong — and how to prevent it
Mixed latency between members causes packet reordering that hurts TCP; use per-flow (not round-robin) schedulers. 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.
Reading Channel Bonding as a promise rather than a conditional. Every number here is of the form “if these inputs, then this result”; when an input moves, the honest response is to recompute rather than to defend the old figure.
This model has its own particular trap: Link 1 carries ≈5.4 % of the response per ten percent of error, so effort spent elsewhere is largely decorative.
A final trap is presentation: reporting Channel Bonding 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.
Before you trust your Channel Bonding: a short checklist
- Compare the output against one published benchmark or a colleague’s independent estimate.
- Compare the result with one independent method or published benchmark.
- Put Link 1 under a magnifier; the sensitivity table above is the reason why.
- Record the date and the inputs alongside the number so future-you knows what was assumed.
- Check that every field the formula needs actually arrived from a document, not from recollection.
- Run the ±10 % stress on the top two levers and check that your conclusion survives both.
How to use the Channel Bonding tool properly
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 — gather before you type. Channel Bonding depends on member links, link 1 (mbps), link 2 (mbps), link 3 (mbps), link 4 (mbps). 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. The point of transparency is that a reader can disagree with a specific line rather than with you.
Step 3 — measure what deserves measuring. The ranked levers above tell you where a careful figure pays off. Everything else can stay approximate, which is a licence to stop hunting for data you do not need. When in doubt, prefer the boring input: the interesting one is usually the one you misread.
Step 4 — run the scenario trio. Expected, pessimistic, optimistic. The gap between pessimistic and expected is the number to plan against; the optimistic result is useful only as a ceiling. Numbers are cheap to produce and expensive to retract; the extra minute is the cheapest insurance available.
Step 5 — schedule the next run. In Technology & Computing the inputs drift quietly. Put a reminder a quarter out, re-enter the same fields, and read the change rather than the level. If a result feels obviously right, that is the moment to check the inputs hardest.
Where Channel Bonding matters in practice
Technology & Computing arguments end at arithmetic or they do not end. Channel Bonding is the arithmetic: 172.9 Mbps on the example inputs, reproducible by anyone who types the same numbers. If the verdict changes with a ten-percent nudge, report the nudge alongside the number.
The companion outputs — Realistic single-stream gain and Survivable capacity if worst link dies — 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. Estimates improve most when the worst case is written down in ink.
There is a personal-administration use people overlook: periodic self-checking. Channel Bonding quietly drifts as life changes — rates move, bodies change, costs compound — and re-running it a few times a year catches drift while correction is still cheap. Estimates improve most when the worst case is written down in ink.
Channel Bonding — frequently asked questions
What affects Channel Bonding the most?
Channel Bonding is driven above all by Link 1. Perturbing only that field by ten percent either way produced 182.2 Mbps against the 172.9 Mbps baseline — a ≈5.4 % response, while Link 2 manages ≈4.6 %.
Which matters more: link 2 or link 1?
Link 1, by a factor of about 1.2. Concretely: ten percent on Link 1 is worth ≈5.4 % of Channel Bonding, the same nudge on Link 2 only ≈4.6 %. That ranking is re-computed for each page from that page’s own defaults.
How much does the “Member links” choice change the answer?
Across every option this tool offers, the bonded aggregate ranges from 172.9 Mbps (2 links) to 270.8 Mbps (4 links) with all other inputs held at their example values. The per-option table is printed in the inputs section — this is a decision that genuinely moves the number, not a cosmetic dropdown.
What is a typical Channel Bonding?
On the worked example above Channel Bonding comes out at 172.9 Mbps. Treat that as one point on a distribution rather than a norm: the bands, the companion outputs and the sensitivity ranking tell you how wide the plausible range really is.
How do I calculate Channel Bonding by hand?
Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest is the entire method. Work the inputs in that order — Members: 98 + 84 Mbps — and you will reach 172.9 Mbps on the default figures, the same number this tool prints.
What happens to Channel Bonding if link 1 changes by 10 %?
On these inputs a ±10 % change in link 1 takes Channel Bonding to 182.2 Mbps against the 172.9 Mbps example — around 5.4 % of the headline. The same test on every other field is in the sensitivity section.
Is the Channel Bonding result of 172.9 Mbps good or bad?
The tool answers “what”, not “whether”: 172.9 Mbps carries the verdict “Modest pooling gain” 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.
Which model does Channel Bonding use?
The stated formula: Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest. It is the same arithmetic the vendor calculators and standards documents implement; differences appear only where vendors tune hidden coefficients, which the pitfall section above flags.
Is Channel Bonding accurate?
The arithmetic is exact: Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest 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 172.9 Mbps result as the correct answer to the question you typed — and check the assumptions section before acting on it.
Does bonding raise upload too?
Yes on symmetric protocols (Peplink SpeedFusion etc.); DNS-based “bonding” is just round-robin and raises nothing.
Can I bond fibre + 5G + DSL?
Yes — that is exactly the failover case the survivable column prices: worst-link loss is an event, not a disaster.
Does this Channel Bonding tool store my numbers?
No. The entire calculation runs in your browser session; nothing entered above is transmitted or saved, which is the correct behaviour for sensitive Technology & Computing figures and the reason you can re-run this page as often as you like.
Key terms on this page
- Realistic single-stream gain
- 140.0 Mbps for the Channel Bonding worked case; it sits next to the main result because it carries context the headline leaves out.
- Survivable capacity if worst link dies
- 93.1 Mbps on the example inputs — a companion figure printed beside the headline of Channel Bonding so that no result is read in isolation.
- Weakest link (failover cost)
- 84.0 Mbps for the Channel Bonding worked case; it sits next to the main result because it carries context the headline leaves out.
- Bonded aggregate
- The primary output of this tool: 172.9 Mbps for the default inputs, computed exactly from Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest.
- Worked example
- Every substitution in order, from the example inputs to 172.9 Mbps — the audit trail for the headline figure.
- Verdict band
- The plain-language label — here “Modest pooling gain” — mapping the computed figure onto experience-based ranges for Technology & Computing.
- Sensitivity (±10 %)
- How far the Channel Bonding moves when a single input is nudged ten percent either way; the ranked list on this page is computed live from this engine.
Method, sources and what this tool cannot tell you
Everything above runs on one stated formula, applied without hidden coefficients: Aggregate = Σ links × 0.95 transport overhead; single-stream gain ≈ best link + half the rest. Source of record: Standard multi-WAN/bonding practice (packetization overhead and per-flow scheduler limits). 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.
This page is an estimation aid, not professional advice. The design rule is simple: two people entering identical figures must get identical answers. The sensitivity table above is part of that promise rather than a bonus: it lets you see how much of the result depends on how carefully you measured.
Turning this Channel Bonding 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.
Whoever you are (people who need one trustworthy number before their next decision), the next step is the same: replace the example inputs with your own, note the date, and re-run whenever a figure moves. In Technology & Computing, a dated figure is a trend, and an undated one is a rumour.