How long to download 100 GB at 100 Mbps

Two hours thirteen minutes twenty seconds, and the factors behind it

One hundred decimal gigabytes is 800,000 megabits, because every gigabyte holds 8,000. A 100 Mbps line moves 100 megabits a second, so the payload needs 8,000 seconds, which is 2 hours 13 minutes 20 seconds. Short enough to finish before lunch, and half the wait of the same payload on a 50 Mbps line.

The prefix does the work. A gigabyte is 10⁹ bytes, so 100 GB is 100,000,000,000 bytes and 800,000,000,000 bits, as the NIST metric prefix chart sets out. One hundred megabits a second is 12.5 megabytes a second, since eight bits make a byte, and 12.5 MB/s clears 45 GB an hour.

Per gigabyte the cost is 80 seconds, and a minute clears 750 MB.

A file manager that shows three digit gigabytes is using the binary prefix. The same payload reads 93.13 GiB, since 100,000,000,000 divided by 1,073,741,824 is 93.13, and the meter beside it ticks at 11.92 MiB/s rather than 12.5 MB/s. Nothing is missing. The two scales differ by 7 percent in each direction, which is why a transfer can look smaller and slower than the number on the bill.

The FCC made 100 Mbps the floor in 2024

In March 2024 the FCC raised the fixed broadband benchmark from 25 Mbps down and 3 Mbps up to 100 Mbps down and 20 Mbps up. The order is FCC 24-27, adopted March 14, 2024, and the 25/3 figure it replaced had stood since 2015. The same report set a long term goal of 1 Gbps down and 500 Mbps up, which remains a goal rather than a standard.

That change makes this line the bottom of the modern definition, not a premium tier. Under the old benchmark the same payload took 32,000 seconds, 8 hours 53 minutes 20 seconds. Under the long term goal it takes 800 seconds, 13 minutes 20 seconds. A 100 Mbps plan sits in between, and it is the tier most American households move to when they leave a 25 or 50 Mbps plan behind.

The upload row is the one people skip. A 100 GB archive moving the other way, from a laptop to cloud storage on a line that delivers 20 Mbps up, needs 40,000 seconds, or 11 hours 6 minutes 40 seconds. Five times the download clock for the same payload on the same plan, because the benchmark pairs a fast lane with a slow one. The FCC household guide rates 100 Mbps for several devices at once, which assumes browsing rather than one saturating transfer.

Why a speed test stops at 94 Mbps

A 100 Mbps line carries frames, not files. A standard 1,500 byte IP packet holds 1,460 bytes of TCP payload once the IP and TCP headers are removed, and it leaves the network card as 1,538 bytes on the wire: 14 bytes of Ethernet header, 4 of frame check, 8 of preamble and start delimiter, and a 12 byte interframe gap. Payload over wire is 1,460 divided by 1,538, which is 94.9 percent.

That is the whole 5.1 percent. A speed test on a healthy line reports 94 to 95 Mbps because it measures payload, and the transfer clock follows the payload rate: 8,430 seconds, 2 hours 20 minutes 30 seconds, rather than 8,000. Bigger frames shrink the loss. Jumbo frames at 9,000 bytes reach 99.1 percent, and a tunnel that adds 60 bytes to every packet drops to 87.6 percent.

The VPN row explains a question that shows up on every support forum: the plan is 100 Mbps, the speed test says 94, and the transfer through a work VPN crawls. Two overheads stack, and the second one costs 898 seconds more than the first. Nothing is throttled; the encapsulation is being honest about its cost.

Where the rest goes: airtime, MCS and channel width

Past the router the path decides, and on Wi-Fi the limit is airtime rather than the plan. A 2x2 client on an 80 MHz channel at 5 GHz negotiates a high MCS index and a short guard interval, but every retry, every beacon and every neighbour on the same channel eats slots that no amount of provisioning can recover. Measured payload lands well below the negotiated PHY rate.

The ladder below is what a laptop sees on a 100 Mbps plan in a normal house. Wired Ethernet from the ONT or cable modem holds 94 Mbps. Wi-Fi 6 on 80 MHz holds 88 at close range, Wi-Fi 5 on 40 MHz holds 78 through one wall, a powerline adapter rated at 1 Gbps delivers 55, and a 2.4 GHz link in a far room falls to 42.

A signal to noise ratio of 20 dB supports a much higher MCS index than one of 10 dB, and that gap can halve the negotiated PHY rate before any retry is counted. Moving the access point beats upgrading the plan. A cable beats both, and removes 11,048 seconds from this job.

Shared decoders fit the same budget. One 4K stream asks for 15 Mbps per the published speed table, so it leaves 85 Mbps and the payload needs 9,412 seconds, 2 hours 36 minutes 52 seconds. Three at once leave 55 Mbps and the clock stretches to 14,545 seconds.

One stream, one window, one round trip

A single TCP connection cannot outrun its receive window. The sender may have at most one window of unacknowledged data in flight, so throughput is the window divided by the round trip time. A 64 KiB window at a 40 ms round trip gives 65,536 bytes every 0.04 seconds, which is 1.64 MB/s, or 13.1 Mbps.

To move 100 Mbps at 40 ms a connection needs a 500 KB window, because 12.5 MB/s multiplied by 0.04 seconds is 0.5 MB. Modern stacks scale the window automatically and reach that figure. Older servers, small embedded clients and some proxies never advertise more than 64 KiB, and that is where a fast plan meets a slow single stream.

The fix is parallel connections, and the arithmetic is linear until the line saturates. Four streams at 40 ms reach 52.4 Mbps, which is the same as one stream at 10 ms, and eight streams reach 104.8 Mbps, which is more than the line can carry. That is why four to eight threads is the useful range and sixteen is not.

Loss is the other ceiling, and it bites harder. The Mathis approximation puts single stream throughput near 1,460 bytes divided by the round trip and the square root of the loss rate. At 40 ms and 1 percent loss that is 365,000 bytes a second, which is 2.92 Mbps, so one gigabyte takes 45 minutes 40 seconds. A line that tests at 94 Mbps still hands a single file only 2.92 Mbps on a lossy path.

A dead socket costs more than a slow one

Two hours leaves room for a reboot, a lid close or a roaming handoff. What happens next decides the cost. A client that issues an HTTP range request, or an rsync that diffs blocks, resumes at the right offset and loses 20 to 60 seconds. A client without resume discards a partial file and starts again, so a drop at 60 percent throws away 4,800 seconds of completed work.

The restart row is the expensive one: 12,800 seconds is 3 hours 33 minutes 20 seconds, and the file sits no further along than the resume case that finished at 8,030. Sorting resume before starting is worth more than any tweak to the plan.

An rsync receiver does better than resume on a repeat run, because it only transfers blocks whose checksums differ. On a re-sent archive with a few changed megabytes it can finish in minutes while a plain client pulls all 100 GB again. The catch is CPU on both ends and a delta algorithm that costs more than it saves when the file is genuinely new.

The copy afterwards is the part people forget

The disk never limits a 100 Mbps transfer. The line hands over 12.5 MB/s while a 7,200 rpm drive writes at roughly 120 MB/s, so the file lands on disk long before the progress bar fills. The step that does cost time is the one after the bar reads done: moving the file somewhere else.

A gigabit link to a NAS carries about 110 MB/s, which clears the payload in a little over fifteen minutes. Send it to two places, a NAS for the archive and an external drive for the edit bay, and the second hop runs while the first is still finishing if the client supports it. Copy first, verify second, delete last is the order that survives a power cut.

File systems set a hard floor on what can be written, and it shows up at the worst moment. FAT32 refuses any file above 4 GB, so an old USB stick fails a 100 GB archive near the 4 GB mark even with 200 GB free. exFAT, NTFS, APFS and ext4 all take the size without complaint, and the stick still writes at whatever speed its controller allows.

Measure the line before you commit two hours

Five minutes of testing saves two hours of waiting, and the test that matters is not the headline download number. Run iperf3 with one stream and then with four, and watch the round trip during the run rather than before it. A line that idles at 20 ms and sits at 300 ms while saturated is bloated, and every call in the house suffers even though throughput looks healthy.

Smart queue management is the fix for the latency row, and it costs nothing in transfer time at this rate. fq_codel is standard in OpenWrt and in several consumer firmwares, CAKE arrives with OpenWrt, and both keep the queue short so a saturating transfer no longer adds 200 ms to every packet behind it. Set the shaper to 95 percent of the measured rate, not to the plan rate, or the queue rebuilds at the modem.