SheepDev

Infrastructure estimates

How long will a file transfer take?

Tools to use

Before sending a large backup, you want to know whether it fits the maintenance window. A 100 Mbps label does not mean simply dividing gigabytes by 100. Files are commonly measured in bytes, links in bits, and effective payload throughput needs its own assumption. Make those units and assumptions explicit.

Calculate 1 GiB at 100 Mbps and 80% efficiency

Example assumptions
size: 1 GiB
speed: 100 Mbps
efficiency: 80%

Enter 1 GiB, 100 Mbps, and 80%. The result is 107.3741824 seconds, about 1 minute 47.37 seconds, at an effective 80 Mbps. The 80% here is an example assumption, not a measurement or a guarantee for your connection.

Formula with aligned units
1,073,741,824 byte × 8
÷ (100,000,000 bit/s × 0.8)
= 107.3741824 s

Multiply bytes by eight, then divide by effective bits per second. Eighty percent is 0.8, not 80. Using 80 creates a factor-of-100 error; omitting the byte-to-bit conversion creates a factor-of-eight error. Check these before interpreting an implausibly short estimate.

Switching to 1 GB changes the result to 100 seconds

Change only GiB to GB while keeping 1 and the result becomes 100 seconds: 1 GB is 1,000,000,000 bytes, while 1 GiB is 1,073,741,824. That changes the assumed file size, not merely its display unit. For the same file, convert the numeric value as well.

Do not paste MB/s or MiB/s into a Mbps field unchanged. Ignoring efficiency, 100 Mbps equals 12.5 MB/s. A measured 10 MB/s may already be payload throughput; applying another 80% can count the same efficiency loss twice.

Test several efficiency assumptions

For 1 GiB at 100 Mbps, efficiencies of 100%, 80%, and 50% give 85.89934592, 107.3741824, and 171.79869184 seconds. Halving efficiency doubles duration. Before measurement, a range of scenarios communicates uncertainty better than one precise-looking number.

Efficiency must be above zero and at most 100%. Zero gives no finite completion time; above 100% does not fit this definition. If compression reduces the payload, change the transferred size assumption rather than disguising that as efficiency above 100%.

Reverse the calculation for a sixty-second budget

Select required-speed mode with 1 GiB, 60 seconds, 80%, and Mbps. The model requires about 178.96 Mbps. That is not a promise that any plan advertised above that rate will meet the deadline. Doubling size doubles the requirement; doubling allowed time halves it.

For a round-trip check, use the detailed rate rather than only the rounded 178.96. A small deviation from sixty seconds can come from display rounding. Real work also includes setup, connection, verification, and retries, so distinguish payload transfer time from the entire task window.

A faster link need not halve the actual duration

The formula halves time when speed doubles. Actual transfers can instead be limited by source or destination storage, CPU, encryption, or per-file waiting. A mismatch is not automatically a link fault. The tool measures none of these factors; it computes the supplied average-rate model.

One large file and many small files of equal total size may have different effective throughput. Use measurements with a comparable file mix and transfer direction. A download result is not automatically a suitable upload assumption.

Keep the duration together with its assumptions

Record 'about 108 seconds for payload transfer, assuming 1 GiB, 100 Mbps, and 80%' rather than only a duration. Decimal detail is arithmetic precision, not prediction accuracy. Combine scenarios with relevant measurements when planning the work window.

One large file and many tiny files can take different times

The formula returns the same result for the same total bytes, but real transfers repeatedly open files, enumerate entries, check permissions and start operations. With many small files, per-file work may dominate. This calculator has no file-count or per-operation-latency input. Efficiency measured on one large file may not apply to a collection of tiny files.

Archiving and compressing is not automatically faster either: compression and extraction take time, and already-compressed data may shrink little. Entering compressed size estimates transfer only, not completion of the whole workflow. Separate preparation, transfer, extraction and verification rather than hiding every unmodeled phase inside one efficiency percentage.

Improve estimates using effective throughput measured under comparable conditions. Apparent throughput above link capacity calls for checking units, caching and compressed versus uncompressed size, not forcing efficiency above 100%. Clarify what moved and how it was timed. A result with decimal seconds is not evidence of equally precise real-world forecasting.

Sources

Tools to use

Guides →