The bandwidth requirement calculator above turns a description of who is on your network into the connection speed you should actually buy. It takes up to three classes of user with their own downstream and upstream bitrates, adds protocol overhead, applies a peak-load factor, and then divides by a target utilisation ceiling — because a link provisioned to run flat out is a link that feels broken.
Arb Digital publishes this as one of a set of free developer and infrastructure tools. It exists because the obvious calculation — users multiplied by bitrate — produces a number that is reliably too small, and the shortfall does not show up as slower transfers. It shows up as latency, as calls that stutter under load, and as a connection that benchmarks fine at 3am and is unusable at 11am.
What This Bandwidth Requirement Calculator Does
It works forwards from demand to capacity in four steps. First it sums concurrent demand across your user classes in both directions, keeping downstream and upstream separate because they are rarely symmetric and the upstream is what usually fails first. Second it inflates that by a protocol overhead percentage. Third it multiplies by a peak factor to cover bursts that an average bitrate hides. Fourth it divides by your utilisation ceiling to get the provisioned speed.
It also estimates monthly data volume, using a duty cycle rather than assuming continuous transfer, and suggests the nearest common commercial link tier above your requirement. The boundary against the adjacent tool on this site matters: our bandwidth converter converts between bits, bytes and their multiples and works out how long a given file takes to download at a given speed. This page does not convert anything — it sizes required capacity from a population of users. Different question, different page.
How to Use It
- Group your users by what they do. Three classes is usually enough: heavy real-time, ordinary interactive, and a small group doing large transfers.
- Enter concurrent users, not headcount. A 200 person office rarely has 200 people transmitting simultaneously; use your observed peak concurrency.
- Take bitrates from the vendor. Every conferencing, streaming and VDI product publishes its own network requirements, and they change between versions.
- Set overhead, peak factor and utilisation ceiling. These three turn a demand figure into a purchasing figure.
- Check the upstream number separately. On an asymmetric connection it is almost always the constraint, and it is the one people forget to read.
The Formula and How It's Calculated
Raw concurrent demand in each direction is Σ (usersi × bitratei) across your classes. The provisioned figure is then required = raw × (1 + overhead) × peak factor ÷ utilisation ceiling. Monthly volume is (raw down + raw up) × 3,600 × busy hours × busy days × duty cycle ÷ 8, converted from megabits to gigabytes.
A worked example using the defaults. Class A is 25 users at 3 Mbps down and 1.5 up, giving 75 and 37.5. Class B is 60 users at 1.5 and 0.3, giving 90 and 18. Class C is 5 users at 15 and 5, giving 75 and 25. Raw totals are 240 Mbps down and 80.5 Mbps up. Adding 10 percent overhead gives 264 and 88.55; a 1.3 peak factor gives 343.2 and 115.1; dividing by a 70 percent ceiling gives 490.3 Mbps down and 164.5 Mbps up. That points at a 500 Mbps service rather than the 250 Mbps one the raw figure alone might have suggested.
Why You Never Size a Link to 100 Percent
This is the most important idea on the page. Network links do not degrade gracefully as they fill. Below roughly 70 percent utilisation, queues stay short and latency stays flat. Above it, queue depth rises non-linearly, and because every interactive protocol is round-trip bound, that queuing is experienced by users as sluggishness rather than as a throughput number.
The effect is worst for exactly the traffic people care about most. A large file transfer does not mind waiting a few extra milliseconds in a queue. A voice or video call does, and a page load that needs several sequential round trips multiplies every added millisecond. This is also why bufferbloat is such a persistent problem: oversized buffers hide packet loss by adding delay, so a saturated link reports healthy throughput while feeling terrible. Sizing to a ceiling of 60 to 80 percent, and running sensible queue management, is what keeps a connection feeling fast.
Upstream Is Where Connections Actually Fail
Most consumer and many business connections are strongly asymmetric — a service sold as "1 Gbps" may carry a small fraction of that upstream. Meanwhile the traffic mix has shifted decisively toward symmetric use: every video call uploads as well as downloads, cloud backup and file sync push constantly, and anyone hosting anything is upstream-bound by definition.
The failure mode is confusing when you first meet it. A saturated upstream breaks downstream performance too, because TCP acknowledgements travel upstream. When the upstream queue fills, ACKs are delayed, senders slow down, and downloads collapse on a link with plenty of spare downstream capacity. That is why this tool reports the two directions separately rather than adding them: they are provisioned separately, they saturate separately, and one takes the other with it. Test the real behaviour with an internet speed test under load rather than on an idle line.
Concurrency Is Not Headcount
The single biggest error in bandwidth sizing is multiplying total users by a peak bitrate. In an office of 200, the number simultaneously transmitting at any instant is far smaller — people read, think, type and attend meetings. Concurrency ratios vary enormously by workload, and the only reliable source is your own monitoring: take the 95th percentile of observed concurrent sessions rather than a theoretical maximum.
Two refinements worth applying. Peak concurrency is not evenly distributed through the day — Monday morning and the top of every hour, when scheduled meetings start, produce sharp spikes that an hourly average completely hides. And concurrency correlates within classes: if one team starts a company-wide broadcast, the class that consumes it goes to full concurrency at once. The peak-load factor in this tool is a blunt instrument for exactly that, which is why it defaults above 1.0 rather than at it.
What the Model Deliberately Ignores
Throughput is not the only thing that determines whether a connection performs. Latency and loss matter independently, and on long paths TCP throughput is bounded by the bandwidth-delay product and the receive window rather than by link speed. RFC 7323, TCP Extensions for High Performance covers exactly this: the standard 16-bit window field caps the window at 64 KiB, and when the bandwidth-delay product exceeds that, the receive window rather than the link becomes the limit — which is why window scaling exists. If you are validating a link against a contracted speed, RFC 6349, Framework for TCP Throughput Testing sets out a methodology for doing it properly, including how to establish path MTU, baseline round-trip time and the required window sizes first.
The model also ignores caching and content delivery, which can remove a large fraction of downstream demand; traffic shaping and quality of service, which change who suffers when the link is full; and any redundant or failover path. For the media side of the estimate, our streaming bitrate calculator and video file size calculator work out per-stream figures, and the data storage converter handles the volume units.
Arb Digital builds web applications and infrastructure where performance is measured, not assumed. See what we do, or tell us what is falling over at peak.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Using headcount instead of concurrency — it inflates the requirement wildly and destroys the credibility of the whole estimate.
- Ignoring upstream — it saturates first on asymmetric links, and when it does it drags downstream performance down with it.
- Sizing to 100 percent utilisation — latency rises long before throughput runs out, and users feel latency.
- Forgetting protocol overhead — application bitrates are payload, and framing at every layer adds to it.
- Treating the monthly volume as capacity — a data cap and a link speed are unrelated constraints, and both can bite.
Related Free Tools From Arb Digital
Use the bandwidth converter for unit conversion and transfer times, the streaming bitrate calculator for per-stream figures, the data storage converter for volume units, the uptime SLA calculator for availability budgets and the Amdahl's law calculator for the compute side of scaling. The full free online tools hub lists every calculator we publish.
Frequently Asked Questions
It depends entirely on what they are doing. With the default mix — 25 users at 3 Mbps, 60 at 1.5 Mbps and 5 at 15 Mbps — raw demand is 240 Mbps down. After 10 percent overhead, a 1.3 peak factor and a 70 percent utilisation ceiling, the provisioned figure is 490 Mbps.
Because latency rises sharply as a link approaches saturation, and interactive traffic is round-trip bound. A link at 95 percent utilisation still moves data but feels slow. Sizing so that peak demand lands at 60 to 80 percent of capacity keeps queues short.
Concurrent. Total headcount overstates demand badly, because most people are not transmitting at any given instant. Take the 95th percentile of observed concurrent sessions from your own monitoring rather than a theoretical maximum.
Because they are provisioned separately on most connections and they saturate separately. Upstream is usually far smaller and now carries video calls, backup and sync. A full upstream also delays TCP acknowledgements, which collapses downstream throughput.
Application bitrates describe payload, while Ethernet, IP, TCP and TLS framing all add bytes on top. Ten percent is a common working allowance for typical packet sizes; small-packet real-time traffic carries proportionally more overhead than bulk transfer does.
Only if throughput is the constraint. If the problem is latency, packet loss, an undersized TCP window on a long path, or a saturated upstream, more downstream capacity changes nothing. RFC 6349 sets out a methodology for testing what is actually limiting you.
Because monthly data volume is not peak rate multiplied by hours. Traffic flows in bursts with idle gaps, so assuming continuous transfer at the peak rate overstates volume by several times. The duty cycle is the share of the busy period during which data is actually moving.
This tool produces capacity estimates from the figures you supply. Application bitrates should be taken from the vendor's published requirements, and any contracted service level should be validated by measurement.
