Computer & IT
Network Uplink Capacity Planner Calculator
Apply peak factor and simultaneity to average traffic, add safety margin, derate link capacity, and compare required whole uplinks with installed usable Mbps. A packet-lane view shows demand crossing the link bank.
Coincident peak demand-
Demand with safety margin-
Usable capacity per unit-
Whole units required-
Installed usable capacity-
Installed capacity margin-
Positive capacity shortfall-
Utilization at design demand-
Installed units above requirement-
Installed capacity less average demand-
Decision view
Traffic demand and uplink lanes
Traffic demand and uplink lanesSafety-adjusted Mbps is distributed through installed usable uplinks while aggregate headroom and utilization remain visible.
Exact scenario comparisonDesign safety margin (%) changes while all other entered assumptions remain constant.
| Design safety margin (%) | Coincident peak demand | Demand with safety margin | Usable capacity per unit | Whole units required | Installed usable capacity | Installed capacity margin | Positive capacity shortfall | Utilization at design demand | Installed units above requirement | Installed capacity less average demand |
|---|
How to use Network Uplink Capacity Planner Calculator
- Use measured traffic from intervals short enough to reveal meaningful peaks.
- Choose simultaneity based on real applications, sites, or clients rather than assuming every source peaks together.
- Review required links and utilization, then separately evaluate latency, loss, redundancy, and burst behavior.
Calculator guide
Understanding Network Uplink Capacity Planner Calculator
An uplink should be sized for coincident peak traffic and operational headroom, not merely average Mbps.
Calculation method
How the calculation works
Convert average network uplink demand into coincident peak and safety-adjusted design demand, derate each unit by usable efficiency, round required units upward, and compare required and installed capacity. Average Mbps × peak factor × simultaneity gives coincident peak; safety margin raises design traffic; link rating × usable efficiency gives usable Mbps per uplink.
Packet path
Map traffic through installed uplink lanes
The visualization separates design traffic, each usable link lane, aggregate installed Mbps, and spare headroom.
Worked situations
Practical examples
- A 75 Mbps service at 88% usable capacity contributes 66 Mbps in this screen.
- Three installed links provide 198 Mbps usable aggregate capacity if traffic can actually be distributed.
- A brief microburst can cause packet loss even when interval-average utilization is below 100%.
Better inputs
Useful tips
- Use percentile and peak measurements alongside averages.
- Account for protocol overhead, asymmetric service, QoS, and failover capacity.
- Confirm whether links can aggregate or are restricted to separate paths.
Before relying on the result
Limitations and common mistakes
- The calculator does not model latency, jitter, packet loss, TCP behavior, application QoS, or provider contention.
- Multiple links do not automatically combine for one flow.
- Final network design requires topology, failover, security, hardware, and service-provider review.
Reference
Key terms
- Mbps
- Megabits per second, the throughput unit used by this page.
- Coincident traffic
- Average traffic adjusted for peak and simultaneous demand.
- Usable uplink
- Rated link speed multiplied by entered efficiency.
- Headroom
- Installed usable Mbps remaining above design traffic.
Important note
Calculated from the entered technical values using the displayed model. Validate topology, workloads, capacity, security, redundancy, and observed performance before implementation.
Frequently asked questions
Does two 1 Gbps links always provide 2 Gbps to one download?
No. Aggregation method and flow distribution determine usable throughput.
Does this include protocol overhead?
Only if represented by the entered efficiency.
Can failover capacity be modeled?
Yes, by entering only links available during the intended failure condition.
Why can performance be poor below 100% utilization?
Latency, bursts, queues, loss, and application behavior can become limiting first.