marrakeshh - Fotolia

Get started Bring yourself up to speed with our introductory content.

How to calculate network bandwidth requirements

Figuring out how to calculate bandwidth requirements is vital to ensuring your network runs smoothly, and it's best to get the formula correct from the beginning.

Bandwidth requirements vary from one network to another, and how to calculate bandwidth properly is vital to building and maintaining a fast, functional network.

As most network administrators can attest, bandwidth is one of the more important factors in the design and maintenance of a functional LAN or WAN. Unlike a server, which can be configured and reconfigured throughout the life of the network, bandwidth is one of those elements of network design that is usually optimized by figuring out the correct bandwidth formula for your network from the outset.

Wondering how to calculate bandwidth requirements when designing the network? What specific considerations apply? These are some of the questions we'll answer in this tip.

Understanding bandwidth

Bandwidth refers to the data rate that is supported by the network connection or the interfaces that connect to the network. It represents both volume and time, representing the amount of data that can be transmitted between two points in a set period of time. It is usually expressed in terms of bits per second (bps), or sometimes in bytes per second (Bps).

Network bandwidth represents the capacity of the network connection, though it's important to understand the distinction between theoretical throughput and real-world results when figuring out the right bandwidth formula for your network. For example, a 1000BASE-T -- which uses unshielded twisted-pair cables -- Gigabit Ethernet (GbE) network can theoretically support 1,000 megabits per second (Mbps), but this level can never really be achieved in practice because of hardware and systems software overhead.

One point to consider when thinking about how to calculate bandwidth needs on your network is this: Bandwidth should not be confused with throughput, which refers to speed. While high-bandwidth networks are often fast, that is not always the case. A helpful metaphor when thinking about bandwidth is cars on a highway. A high-bandwidth network is like a six-lane highway that can fit hundreds of cars at any given moment. A low-bandwidth network is like a single-lane road in which one car queues directly behind another.

Although the large highway is likely to move vehicles faster, rush-hour traffic can easily bring cars and trucks to a standstill. Or, perhaps, the cars cannot get onto the highway quickly because it's clogged with large delivery trucks that take up a lot of space on the road. Similarly, even a high-bandwidth network can run slowly in the face of problems, such as congestion and bandwidth-hungry applications.

These very points make calculating bandwidth requirements a challenge, yet the consequences of getting the bandwidth formula wrong are considerable. If you don't procure enough bandwidth, you all but guarantee the network will run slowly. However, significantly overprovisioning bandwidth can be cost-prohibitive for most enterprises.

So, how do you determine the right formula that will meet your bandwidth requirements? The process begins with asking the right questions: What applications are users running, and what is the performance service-level agreement for these applications? I know some network managers who are only concerned with how many users are on a virtual LAN. What you really need to know is what the users will be doing on the network. It's possible that 200 users will cause less of a bottleneck than a group of three users that really beats the heck out of the network because of some funky client-server application or extensive use of a bandwidth-heavy service, like high-definition video conferencing.

Ethernet speed roadmap

Coming up a formula for how to calculate bandwidth

There are two basic steps to calculating bandwidth requirements:

  1. Determine the amount of available network bandwidth.
  2. Determine the average utilization required by the specific application.

Both of these figures should be expressed in bytes per second. Consider the following formula: A GbE network has 125,000,000 Bps of available bandwidth. This is computed by taking the amount of bits -- in a Gigabit network, that would be 1 billion -- and dividing that by eight to determine the bytes:

1,000,000,000 bps / 8 = 125,000,000 Bps.

After determining the network's bandwidth, you'll have to see how much bandwidth each application is using. Use a network analyzer to detect the number of bytes per second the application sends across the network. To do this, first enable the Cumulative Bytes column of your network analyzer. The next steps in the bandwidth formula are:

  1. Capture traffic to and from a test workstation running the application.
  2. In the decode summary window, mark the packets at the beginning of the file transfer.
  3. Follow the timestamp down to one second later, and then look at the cumulative byte field.

If you determine that your application is transferring data at 200,000 Bps, then you have the information to perform the calculation: 125,000,000 Bps ÷ 200,000 = 625 concurrent users. In this case, the network will be fine even if there are several hundred concurrent users.

Look what would happen, though, if you had a 100 Mbps network: 13,102,000 Bps ÷ 200,000. You would then have a network that could not support more than approximately 60 users running the application concurrently. Knowing how to calculate bandwidth formula is, therefore, very important to network administrators.

A final recommendation: Capture the data in 10-second spurts and then do the division. It's also a good idea to check multiple workstations to ensure the number is reflective of the general population. It's also important to determine how many concurrent users you will have.

Next Steps

Real-world network speed troubleshooting

APM tools can help diagnose network performance issues

Buyer's guide to network performance monitors

This was last published in May 2017

Dig Deeper on Campus area network