Mbit/sec versus GByte/day

When sizing communication links, especially costly satellite links, I am frequently asked to answer two questions.

1. Given a carrier capable of x Mbps throughput, how many gigabytes could I transmit in one day?
2. What is the minimum number of megabits per second (Mbps or Mbit/sec) necessary to transmit x gigabytes (GB) in one day?

I call this the “bulk upload” problem. A customer wants to upload a large amount of data and they must do it in a certain time frame. For instance, moving a copy of a database off site every 24 hours.

The Math

The two questions above are really the same equation. Given x, solve for n:

Solving for n in this equation is a matter of unit cancellation. But first, we must clarify some terms:

• In communications, 1 GByte = 1000 MByte. Metric prefixes are divisible by 1000, not 1024. Unlike hard drive manufacturers, there is no disagreement about this among communications providers.
• 1 Byte = 8 bits. When abbreviating bytes, use uppercase B, such as “MB” or “kB”. When abbreviating bits, use lowercase b, such as “Mb” or “kb”. I sometimes use “GByte” and “Mbit” to clarify, but I always capitalise correctly when representing units.
• 1 day = 86400 seconds. Just ask any DNS administrator.

So let’s solve for n.

So n = 10.8. This is the magic number we can use to quickly answer this question. Given a sustained data rate of x mbit/sec, you can upload (x*10.8) GB/day. For example, with a data rate of 2 mbit, you can upload 2*10.8 = 21.6 GB/day.

What about the opposite question?

Given a need to upload x GB in one day, you need a data rate of (x/10.8) mbit/sec. To upload 15 GB/day, you need a sustained data rate of 15/10.8 = 1.388 mbit.

The Reality

However, none of these numbers hold up to a real world FTP throughput test. Why? Because I said “sustained data rate”. A 2 Mbit leased line does not equal a 2 Mbit TCP transfer rate. Most network protocols that people use to transfer bulk data or measure link speed are based on TCP, including FTP and HTTP.

Over a low-latency link, TCP produces a reliable throughput of about 85% of the channel. This is due to protocol encapsulation overhead (the Ethernet, IP, and TCP headers), as well as TCP flow control, maximum segment size, and window scaling. Over high-latency links such as satellite, ordinary TCP has much worse performance. On all modern satellite modems, TCP acceleration is used to counter this limitation.

So, assuming that you have a standard low-latency terrestrial service, or a TCP-accelerated, high-latency satellite service, you should calculate bandwidth as about 85% of the channel. Going back to our first example above, with a data rate of 2 Mbit, you can upload (2 * 10.8 * 0.85) = 18.36 GB/day. And if your application depends on uploading 18 GB a day, I suggest adding another 5% margin.

What about UDP? It doesn’t have TCP’s flow control features, but it still suffers from bit errors and retransmissions. In practice I have rarely seen UDP applications exceed 95% of the data channel. Back to that first example, with a data rate of 2 Mbit, you can upload with a UDP application at most (2 * 10.8 * 0.95) = 20.52 GB/day.

The Footnotes

c is a real pain in the ass. You might think it’s fast, but given the altitude of geosynchronous satellites and modern latency-sensitive applications, it’s actually a serious limitation.

I haven’t tried using a LaTeX plugin for WordPress yet, so the equations above are images. You can download the LibreOffice Math source file here.