TeraAirlift

Transfer Planning

How Long Does It Take to Transfer 1 TB Over the Internet?

Calculate a practical 1 TB transfer estimate and learn why real-world throughput differs from headline bandwidth.

Richard Parker7 min read

Blue and purple light glowing through fiber-optic strands

A 1 TB transfer takes approximately 2 hours 29 minutes at 1 Gbps or 24 hours 53 minutes at 100 Mbps, one direction, using the calculator's 12% planning-overhead assumption. Those are planning estimates, not guarantees. The real completion time depends on the slower end-to-end constraint: the sender's upload, the recipient's download, the network path, local storage, and the service receiving the data.

Theoretical, modeled, and observed time

Three different answers can all be valid:

  • Theoretical time assumes every bit of the advertised link is available to file payload continuously. It is a mathematical floor.
  • Modeled time applies the current calculator's documented assumption. Here, transfer seconds = (file bytes × 8 × 1.12) / bandwidth bps. The 1.12 multiplier adds a 12% planning allowance to the effective data size. It is the calculator's modeling choice, not a physical law or measured constant.
  • Observed time is what a real transfer achieves. Measure it on the actual route because protocol overhead, latency, loss, contention, disks, and cloud limits can move the result in either direction from a planning estimate.

For one decimal terabyte transferred in one direction:

| Link speed | Theoretical time | Modeled time (12% planning overhead) | |---|---:|---:| | 100 Mbps | 22 h 13 m | 24 h 53 m | | 500 Mbps | 4 h 27 m | 4 h 59 m | | 1 Gbps | 2 h 13 m | 2 h 29 m | | 2.5 Gbps | 53.3 min | 59.7 min | | 10 Gbps | 13.3 min | 14.9 min |

Why 1 Gbps does not mean 1 GB per second

NIST distinguishes decimal and binary storage prefixes: 1 TB is 10^12 bytes, while 1 TiB is 2^40 bytes. A decimal 1 TB dataset therefore contains 8 × 10^12 bits. Network rates are quoted in bits per second, so:

1 Gbps / 8 = 125 MB/s

That is 125 MB/s at line rate, before overhead—not guaranteed file throughput. At 1,500-byte MTU, Dell's packet-overhead breakdown shows 1,460 payload bytes in a 1,538-byte wire frame, about 94.9% efficiency. Framing is only one cost, which is why the current calculator adds a 12% planning allowance to the effective data size. That assumption is not a measured efficiency, and your workload may perform differently.

Upload speed is usually the number to check

If a plan advertises “500 Mbps,” confirm whether that is download speed. A connection with 500 Mbps down but 20 Mbps up does not upload 1 TB in the table's five-hour estimate. At 20 Mbps, the upload is about 111 hours theoretically or 124 hours under the current calculator's 12% planning-overhead model.

That example is illustrative, but asymmetry is common. The FCC's U.S.-only Thirteenth Measuring Broadband America report, based on measurements from September–October 2022, found a weighted mean advertised upload speed of 71.8 Mbps versus 467 Mbps download. It characterized non-fiber download-to-upload ratios as typically 5:1 to 10:1, while fiber was generally symmetric. Those historical U.S. measurements are context, not a description of every current connection.

For delivery planning, use the sender's upload for the outbound leg and each recipient's download for the inbound leg. If the workflow requires a return transfer, estimate that separately too.

What changes the observed result?

A bandwidth test is useful, but it does not test every part of the transfer path.

  • Latency and TCP windows: A single connection needs enough data in flight to fill a fast, distant path. Microsoft's TCP/IP tuning guidance shows how round-trip time and receive-window size can cap one stream below the link rate.
  • Packet loss: Retransmissions are especially costly on long paths. ESnet documents a 90 ms path where 0.0046% loss coincided with 490 Mbps in one direction versus 8.2 Gbps on the clean direction. That case illustrates sensitivity; it is not a universal multiplier.
  • Shared links: Other uploads, Wi-Fi conditions, ISP congestion, VPNs, and office traffic reduce the bandwidth available to the job. The FCC report also found delivered performance varied among measured U.S. providers and technologies.
  • Local media: Files must be read and written quickly enough. USB-IF lists USB 3.2 signaling rates of 5, 10, and 20 Gbps, but a spinning drive connected to a fast port will not necessarily sustain the port's rate.
  • Cloud-side limits: The destination can impose account or request ceilings. For example, Azure documents regional ingress and egress targets for standard storage accounts.
  • Parallelism: Multiple requests can keep a high-bandwidth path busier than one stream. Microsoft recommends benchmarking AzCopy before adjusting its concurrency. More parallelism is not automatically better.

The practical response is to test representative data and leave schedule margin, not to assume the advertised rate will hold uninterrupted.

Choose a delivery method from the deadline backward

  • Cloud drives are convenient when collaborators already have access and the provider's file-size, quota, and synchronization behavior fit the job.
  • Purpose-built transfer tools suit recurring, deadline-sensitive deliveries that benefit from visible queues, progress, ETAs, retry-friendly operations, and auditable history.
  • Object storage with a CLI offers control and parallelism for technical teams prepared to manage credentials, commands, and recipient access.
  • Physical shipment can win when upload bandwidth makes the online timeline unacceptable, but handling, copying, courier time, and a second copy at the destination all count. Compare the full workflow with shipping a drive versus transferring online.

Recipient skill, delivery frequency, security policy, and the cost of a missed deadline matter alongside raw speed. For preparation and handoff considerations, see how to send a 1 TB file. If this transfer is the start of a larger estimate, compare the 10 TB transfer-time guide.

Where TeraAirlift fits

TeraAirlift is a desktop transfer operations console for teams that need visibility during large deliveries. It provides a queue with progress and ETA, retry-friendly operations, linkless recipient delivery, SHA-256 integrity verification, and transfer history and logging. It does not remove network, storage, or cloud constraints, and no speed is promised here.

The app is available as a Windows download, with Mac coming soon. Teams in post-production, LiDAR and reality capture, and construction can use the arithmetic in this article regardless of which transfer method they choose.

Sources

Server racks with network switches and orange cables

Transfer Planning

How Long Does It Take to Transfer 10 TB?

Model the time required to transfer 10 TB online, including bandwidth, overhead, and other practical planning considerations.

Richard Parker7 min read

Plan your next large-file transfer

Schedule a demo or download the Windows client to explore the TeraAirlift workflow.

End-to-end desktop clients — you send from the app; your recipient opens TeraAirlift and pulls from Available Downloads.