Bandwidth vs data transfer: Mbit/s, terabytes and what a 1 Gbit/s port means

Copy a 10 GB backup to a new server with a 1 Gbit/s port and, even if nothing else slows it down, it takes a little under a minute and a half, not ten seconds. Then read the plan again: it includes 6 TB of traffic a month, which looks tiny next to a port that could, on paper, move hundreds of terabytes. Nothing is wrong with either number. They measure different things, in units that happen to share letters.

The port speed is a rate: how fast data can flow at any moment. The traffic figure is an amount: how much flowed over the month. Once you can convert between the two, and between bits and bytes, you can look at any plan and tell whether it fits a website, a video stream, a VPN or a game server before you pay for it.

Port speed is a rate, data transfer is an amount

Think of the network port as a pipe. Its speed, written in bits per second, says how much can pass through at once: a 1 Gbit/s port can carry a billion bits every second and no more. It says nothing about how much actually passes. A port can sit nearly idle for a month, or run flat out for a day and then go quiet.

Data transfer, also called traffic, is the water that went through the pipe: the total number of bytes counted over a billing period, usually a month. Time is the only thing that links the two numbers. An amount is a rate multiplied by how long it was held, so a slow rate held all month can move more than a fast one held for an hour.

The word bandwidth muddles this, because people use it for both. Strictly it is the rate, the width of the pipe, but plenty of plans say "bandwidth" when they mean the monthly amount. The unit tells you which one you are looking at. Anything per second (Mbit/s, Gbit/s, MB/s) is a rate. Anything in bytes without "per second" (GB, TB) is an amount.

Neither number says how soon the first byte arrives. That delay is latency, set mostly by distance and the route, and a wider pipe does not shorten it; where your server is covers it.

Bits on the wire, bytes on the disk

Link speeds are counted in bits, because a link sends a stream of individual bits. File sizes, disk sizes and monthly traffic are counted in bytes, and a byte, symbol B, is eight bits.¹ Careful writing spells the bit out (Mbit/s); marketing shortens it to a lower-case b (Mbps). Either way, Mbit/s and MB/s are different units, and the second is eight times the first.

To turn a port speed into bytes, divide by eight. 1 Gbit/s is 1,000,000,000 bits per second, which is 125,000,000 bytes per second, or 125 MB/s. That is the ceiling for everything the port carries, headers included. The 10 GB backup needs at least 10,000 MB ÷ 125 MB/s = 80 seconds, and a few more in practice, because every packet spends part of its size on headers rather than your data (the VPN example below shows how much).

When a terabyte is not a terabyte

The second trap is the prefix. In the International System of Units, kilo, mega, giga and tera are powers of ten: 10³, 10⁶, 10⁹ and 10¹².² Computing borrowed them for powers of two, because 2¹⁰ = 1,024 is very nearly 1,000, and so the same word came to mean two different numbers.¹

In December 1998 the International Electrotechnical Commission approved a standard with separate names for binary multiples: kibi (Ki) for 2¹⁰, mebi (Mi) for 2²⁰, gibi (Gi) for 2³⁰ and tebi (Ti) for 2⁴⁰. Under them, 1 MB is 1,000,000 bytes and 1 MiB is 1,048,576; 1 GB is 10⁹ bytes and 1 GiB is 1,073,741,824.¹

Network speeds are decimal. NIST records that some LAN designers once read a megabit per second as 2²⁰ bits per second, while telecommunications engineers all read it as exactly a million.¹A 1 Gbit/s port is exactly 10⁹ bits per second. The confusion starts when a tool on your server reports traffic in binary units, and worse, when it prints them with the decimal symbols.

The gap grows at every step, which is why it bites hardest at the scale of monthly traffic. vnStat, a common traffic counter on Linux, shows the whole problem in one setting: its UnitMode option picks between IEC prefixes (KiB, MiB, GiB) in powers of 1,024, an older style that writes KB, MB and GB but still means powers of 1,024, and SI prefixes in powers of 1,000.³ So 6 TB of traffic can appear as 6.00 TB, as 5.46 TiB (6 × 10¹² ÷ 2⁴⁰), or as 5.46 "TB" in the old style.

From a port speed to terabytes a month

Here is the conversion for a 1 Gbit/s port that never pauses for a whole 30-day month.

1. 1

   Turn bits into bytes

   1 Gbit/s is 1,000,000,000 bits per second. Divided by 8, that is 125,000,000 bytes per second: 125 MB/s.

2. 2

   Count the seconds

   A 30-day month has 30 × 24 × 3,600 = 2,592,000 seconds.

3. 3

   Multiply

   125 MB/s × 2,592,000 s = 324,000,000 MB, which is 324 TB.

A 31-day month has 2,678,400 seconds and gives 334.8 TB. The same 324 TB is about 294.7 TiB in binary units, which is the figure a tool set to IEC prefixes would print.

1 Gbit/s, in bytes per second

125MB/s

1 Gbit/s held for a 30-day month

324TB

1 Mbit/s held for a 30-day month

0.324TB

1 TB a month, as an average rate

3.09Mbit/s

The third number is the one worth remembering: every megabit per second held for a whole month moves about a third of a terabyte. 10 Mbit/s all month is 3.24 TB, 100 Mbit/s is 32.4 TB. Turned round, each terabyte a month is an average of 8 × 10¹² bits ÷ 2,592,000 s, about 3.09 Mbit/s.

What an allowance means as a rate

The same arithmetic tells you what a monthly allowance is. A 6 TB allowance is 48 × 10¹² bits. Spread evenly over 2,592,000 seconds, that is an average of 18.5 Mbit/s, 1.9 per cent of a 1 Gbit/s port. You could also spend it all at once: at the full 125 MB/s, 6 TB is gone in 48,000 seconds, about 13 hours and 20 minutes.

The port is sized for moments, the allowance for the month. A 1 Gbit/s port with a few terabytes of traffic lets a single transfer run at full speed, but over a month the average has to stay at a few per cent of the port or less.

Peaks size the port, the average fills the month

Real traffic is not flat. A site whose visitors live in one time zone is busiest in their evening and nearly idle before dawn. The drawing below is one made-up but typical-shaped day, with numbers chosen so the arithmetic is easy to follow.

One curve, two questions. Can the port carry it? Look at the peak: 100 Mbit/s at nine in the evening, a tenth of a 1 Gbit/s port, so yes, with room to spare. How much does it use? Look at the area under the curve, which is the average rate multiplied by the time: 20 Mbit/s × 86,400 s ÷ 8 = 216 GB for the day, and 6.48 TB over thirty days like it. That is more than a 6 TB allowance, even though the port was never more than a tenth full.

The mistakes run in both directions. Size the port from the average and the evening chokes, because the peak is five times higher. When more arrives than a port can send, packets wait in a queue, and once the queue is full new arrivals are dropped. TCP takes each loss as a sign of congestion and backs off, so pages and streams stall for everyone at once.¹³ Size the monthly total from the peak (100 Mbit/s held for 30 days is 32.4 TB) and you buy five times the traffic you use. How far the peak sits above the average depends on your audience: one time zone makes a sharp evening peak, visitors spread around the world flatten it. Your own graphs are the only reliable guide.

95th percentile billing: paying for the busy hours

Some network contracts are billed on a rate rather than an amount. The common method is called burstable, or 95th percentile, billing, and it lets usage go above a committed rate for short periods without paying for a higher commitment.⁵ It works in four steps.

1. 1

   Sample the rate

   Measure the average rate on the link at regular intervals, in most cases every five minutes.

2. 2

   Sort the month

   At the end of the month, sort all the samples from highest to lowest.

3. 3

   Drop the top 5 per cent

   Throw away the highest 5 per cent of samples, the rarest spikes.

4. 4

   Bill the next one

   The highest sample left is the rate billed for the whole month.

Five minutes is the usual sampling interval, not a universal one.⁵With five-minute samples, a 30-day month has 30 × 24 × 12 = 8,640 of them; 5 per cent is 432 samples, or 36 hours. So bursts that add up to less than about 36 hours in a month do not raise the bill.⁵

If every day of a month looked like the illustrative one, the billed rate would be about 72 Mbit/s: more than three times the 20 Mbit/s average, and below the 100 Mbit/s peak. That is the intent: a link has to be built for its busy periods, and the percentile follows that need more closely than the mean or the single highest sample does.⁵

Details vary between contracts, and direction is the big one. LibreNMS, an open-source monitoring system with a billing module, can account by total data transferred or by 95th percentile; for the percentile it bills the higher of the inbound and outbound figures by default, with an option to add the two together.⁶To see the figure for your own server, vnStat's --95th option calculates it for the current month from five-minute data, for received, transmitted and total traffic, along with the minimum, average and maximum rates.⁴ A fixed monthly allowance is the other model: it counts the amount, so how fast the bytes went does not matter, only how many there were.

Estimating what you actually need

Every estimate is the same multiplication: how much one unit of use sends, times how many units there are in a month. What changes from one workload to the next is the unit, and whether the peak or the total is the number that binds.

A website: page weight times page views

The HTTP Archive's Web Almanac put the median page weight in October 2024 at 2,652 KB on desktop and 2,311 KB on mobile, up from 1,208 KB and 505 KB ten years earlier.⁷ Take the mobile median, about 2.3 MB, as a starting point (the Almanac does not say whether its KB is 1,000 or 1,024 bytes; the difference here is under 3 per cent). 100,000 page views a month × 2.311 MB = 231 GB. One terabyte covers about 430,000 such views (1,000,000 MB ÷ 2.311 MB).

For your server that is an upper estimate, for two reasons. Returning visitors reuse files their browser has cached, although the Almanac warns that a good part of a page may be downloaded again anyway.⁷And page weight includes bytes that never leave your server: fonts, scripts and analytics loaded from other domains, or images served by a CDN. Weigh your own pages in the browser's developer tools and count only what your server sends.

The rate is tiny. 231 GB over a 30-day month is 231 × 8 × 10⁹ bits ÷ 2,592,000 s, an average of about 0.71 Mbit/s; a busy hour at ten times that is still only 7 Mbit/s. For a website, the monthly total is the number to check, not the port. The server calculator does this sum from your traffic, and the page on hosting websites covers the rest of the sizing.

A video stream: bitrate times hours times viewers

Video is the opposite case: steady, heavy, and multiplied by every viewer. YouTube recommends encoding a 1080p live stream at 30 frames per second at 10 Mbit/s with H.264, and 12 Mbit/s at 60 frames per second.⁸One hour at 10 Mbit/s is 10,000,000 × 3,600 ÷ 8 = 4.5 GB. You can test the method on a published figure by running it the other way. Netflix says an hour of high-definition video uses up to 3 GB,¹⁰ and 3 × 8 × 10⁹ bits ÷ 3,600 s is about 6.7 Mbit/s: the same order as the 3 to 5 Mbit/s connection it recommends for 720p and 1080p.⁹ The two do not match exactly, because one is the connection Netflix recommends and the other the most an hour can use.

Now relay a 10 Mbit/s stream from your own server to 50 viewers. Each viewer receives a copy, so while the stream is live the port carries 50 × 10 = 500 Mbit/s: half of a 1 Gbit/s port, which fits. Two hours a night is 500,000,000 × 7,200 ÷ 8 = 450 GB a night, and 13.5 TB over 30 nights. Here the port says yes and the allowance decides the plan. At 100 viewers the stream alone would need the whole port before any overhead, and both limits bind at once. Sending one copy to a platform that serves the viewers costs you one copy: 4.5 GB an hour.

A VPN: every byte crosses the server twice

A VPN server sits in the middle of its clients' traffic. When a client downloads a 1 GB file through the tunnel, the server receives that gigabyte from the internet and then sends it, encrypted, to the client. Five people who each pull 100 GB a month through the tunnel mean 500 GB arriving at the server and a little more than 500 GB leaving it. Whether that counts as 500 GB or about 1 TB against an allowance depends on whether your host counts inbound traffic, outbound traffic or both, so find out before you size the plan.

The "little more" is overhead. Every packet carries headers as well as data. With minimum-size headers, IP and TCP take 20 bytes each, so a segment can carry the packet size minus 40 bytes of data:¹¹ 1,460 bytes in a 1,500-byte packet, 2.7 per cent less than the packet. A tunnel wraps another layer around that. WireGuard sends all of its packets over UDP,¹⁴ whose header is 8 bytes,¹²adds a 16-byte header of its own (a type byte, three reserved bytes, a 4-byte receiver index and an 8-byte counter), and its encryption makes the payload 16 bytes longer.¹⁴

Add an outer IPv4 header and that is 20 + 8 + 16 + 16 = 60 bytes per packet, plus up to 15 bytes of padding, because WireGuard pads the inner packet to a multiple of 16 bytes.¹⁴ If the outer packets are 1,500 bytes, the inner packet can be at most 1,440, which carries 1,400 bytes of data after its own IP and TCP headers instead of 1,460: about 4 per cent less. On a small 100-byte packet it is 60 bytes plus 12 of padding (100 rounds up to 112), 72 per cent extra, which is why tunnel overhead matters more for chatty, small-packet traffic than for downloads. Ethernet adds its own framing on top of all of it. The VPN page and the guide to WireGuard and OpenVPN cover the rest.

A game server: players times rate times hours

A game server sends every connected player a steady trickle of small packets, so the estimate is per player: rate per player × players × hours online × days ÷ 8. With a round number chosen only to show the arithmetic, 100 kbit/s per player and 32 players for six hours a day gives 3.2 Mbit/s at the busiest time, and 3,200,000 × 21,600 s ÷ 8 = 8.64 GB a day, about 259 GB a month. Real per-player rates differ a lot from one game to another, so use a published figure for your game. The calculator has sourced figures for each game it covers, for example Minecraft: Java Edition.

Measure it on your own server

Estimates get you to a plan; after that, the server counts its own traffic. Linux keeps byte counters for every network interface: /sys/class/net/<interface>/statistics/tx_bytes is the number of bytes the device has transmitted, and rx_bytes the number it has received.¹⁵ The counter is a running total rather than a monthly one, and it starts again from zero when the server reboots. It counts whole packets, headers included, so it reads a little above the total size of the files you moved, and the kernel leaves the finer points of what is counted to each network driver.¹⁵ It is in plain bytes, so you choose the prefix when you convert it. Replace eth0 with your interface's name (ip link lists them).

$ cat /sys/class/net/eth0/statistics/tx_bytes1843276533912$ awk '{ printf "%.2f TB  %.2f TiB\n", $1/1e12, $1/2^40 }' /sys/class/net/eth0/statistics/tx_bytes1.84 TB  1.68 TiB

Same bytes, two numbers about 9 per cent apart. For a month-by-month view you need something that keeps history: vnstat -m shows traffic per month, and vnstat --95th gives the current month's 95th percentile.⁴ When your figure and your provider's disagree, check five things in order: the prefix (TB or TiB), the direction (in, out or both), the dates the month starts and ends, the interface, and whether a reboot has reset the counter you are reading.

The mistakes that catch people out

• Reading Mbit/s as MB/s. The tell: a download that levels off a little under 125 MB/s (a little under 119 MiB/s, if the tool counts in binary) has filled a 1 Gbit/s port, and there is no more speed to find.
• Treating the port speed as an allowance. The check: divide the allowance in TB by 0.324 to get the average rate it allows over 30 days. 6 TB comes to about 18.5 Mbit/s.
• Sizing from the wrong number. The tell is in your graphs. If the rate sits flat at the port's limit every evening, the port is too small; if the allowance is used up before the month ends, the allowance is.
• Counting a relay once. Compare rx_bytes with tx_bytes. On a VPN server they climb at nearly the same pace; on a stream relay with fifty viewers, the outbound counter climbs about fifty times as fast as the inbound one.
• Comparing TiB with TB. Two figures about 9 per cent apart are the same bytes in different units until shown otherwise: 6 TB is 5.46 TiB.
• Blaming the port for a slow site. A wider pipe helps only when the pipe is full; if it is not, look at distance. If it is full of traffic nobody asked for, that is a flood, and the guide to DDoS attacks covers it.

Before you choose a plan, run vnstat -m on the server you have now, read last month's total (check whether it is printed in TB or TiB) and compare it with the allowance. Then run vnstat --95th and check that the maximum rate it reports sits well under the port.⁴