Rule of thumb to calculate a transfer time of a 20 Gigabyte file over an IP connection with bandwidth that is less than Gigabit.
Number of raw data in bits: <MATH> 20 000 \text{ Megabytes} * 8 \text{ bits per byte} * 1 000 000 \text{ bits per Megabyte} = 160 000 000 000 \text{ bits} </MATH>
Note that these calculations are for file transfers which is easier to define. Trying calculate 20 GB of interactive traffic is much more difficult because the underlying condition is indeterminate. Beware.
The best possible network performance is achieved when the network pipe between the sender and the receiver is kept full of data, that is, the “in-flight bytes” is set to the maximum that a sender and receiver can buffer before an acknowledgement is issued. This “should” occur when transferring a large file and thus issues such as BDP and TCP Windowing are not really relevant.
When the raw data is packaged into a TCP/IP packet the data set will expand by about 40%.
160 000 000 000 bits plus 40% encoding overhead = 224 000 000 000 bits of network data.
In a real transmission, there is:
The rule of thumb for circuits between 1 to 10 Megabits per second is to reduce the throughput by another:
Adding encryption (IPSec or SSL) will further inflate the amount of transferred data. The actual impact will depend a lot on average packet size. IPSec typically add 40 bytes to the header, which has less impact for a large data transfer with an MTU of 1350 bytes that for an interactive session exchanging packets with an MTU of of 400 bytes.
Often forgotten is the encryption and decryption delay that makes the transfer more latent.
Rule of Thumb: add another 10 to 15% if you choose to encrypt the transfer.
If we transfer this data (without encryption) at 10 megabits per second:
224 000 000 000 bits / 10 000 000 bits per second = 22400 seconds = 373 minutes.
And then:
We obtain:
373 minutes * 20% * 10% = 492 minutes.