10 GB at 100 Mbps is 800 seconds, or 13 minutes 20 seconds

The arithmetic is one division. Ten gigabytes is 80,000 megabits, and a 100 Mbps line carries 100 megabits every second. 80,000 / 100 = 800 seconds. That is 13 minutes and 20 seconds, and it is the number to hold on to for every other case here.

The units are where people go wrong. A gigabyte is a byte count and a megabit per second is a bit rate, so the file has to be multiplied by 8 before the division means anything. Skip that step and 10,000 megabytes divided by 100 looks like 100 seconds, wrong by a factor of eight and in the optimistic direction.

Ten gigabytes is 80,000 megabits, and the factor of 8 does the work

A byte is 8 bits, so the conversion from a file size to a bit count is a multiplication by 8. A 4.7 GB DVD image is 37,600 megabits, which is 376 seconds on this line. A 500 MB episode is 4,000 megabits, or 40 seconds. The formula has no other terms, so a wrong answer almost always comes from a unit that was swapped.

The decimal prefix is the one that matches the bill. NIST lists giga as 10 to the ninth, and a 100 Mbps line is defined in decimal megabits, so a decimal gigabyte is the honest unit for an estimate. The NIST table of SI prefixes is the reference for that usage, and drive makers and network engineers both follow it.

One sanity check catches most slips. A 100 Mbps line moves 12.5 megabytes a second, so a 10 GB file should take about 800 seconds. An estimate of 100 seconds means megabytes were divided by megabits.

What 2 percent to 5 percent overhead looks like on a 13 minute job

Headers and acknowledgements consume line capacity without delivering file bytes. A 1,500 byte IP packet carries 1,460 bytes of TCP payload after a 20 byte IP header and a 20 byte TCP header. Ethernet adds 14 bytes of header and 4 of frame check, which is 58 bytes around 1,460, or 3.97 percent. With the preamble and the inter-frame gap the same packet costs 5.34 percent of the wire.

That is why the planning band is 2 to 5 percent rather than one figure. A shaper that counts IP packets skips the Ethernet layer, and a clean wired path with large reads sits near the bottom. Wi-Fi retries, a VPN tunnel and small packets push toward the top. On a 10 GB file, 2 percent adds 16 seconds and 5 percent adds 42.

Each row is one division: seconds at line rate divided by one minus the overhead fraction. 800 / 0.98 = 816.3 and 800 / 0.95 = 842.1, rounded to the nearest second. A 100 GB transfer carries 13 more minutes at 5 percent on top of 2 hours 13 minutes.

Windows says 10 GiB, and the clock runs to 14 minutes 19 seconds

Windows and most file managers count in binary. What the operating system calls 10 GB is 10 gibibytes, and one gibibyte is 1,073.741824 megabytes. Multiply and the file is 85,899.34592 megabits, so 100 Mbps needs 858.99 seconds, or 14 minutes 19 seconds. It is the same download either way. Only the label changes.

Giga means 10 to the ninth and gibi means 2 to the thirtieth, a distinction the IEC standardized in 1998 and NIST explains in its note on binary prefixes. Drive makers sell decimal terabytes, operating systems report binary ones, and the gap is 7.4 percent at every size from a kilobyte upward.

The effect is a 59 second gap on a 13 minute job, which nobody notices. On a 500 GB archive the same 7.4 percent is 49 minutes. Pick one unit for the calculation and say which one you used.

Progress bars, checkpoints and what 13 minutes of waiting looks like

A 13 minute download is long enough that the progress bar becomes the estimate. Most clients compute the remaining time from the average rate since the start, so the first fast minute sets a number the last minute cannot hold. Watch the rate instead: 12.5 MB/s means on schedule, 6 MB/s means 26 minutes.

The file passes 1 GB every 80 seconds, so 80 seconds is 10 percent, 400 seconds is 50 percent and 720 seconds is 90 percent. A bar that stalls at 43 percent for two minutes is not a slow line, it is a stalled connection.

On a 100 Mbps line every gigabyte costs 80 seconds, so any size is a count of gigabytes times 80. A 10 GB update and a 2.5 GB patch differ by 600 seconds.

Disk time sits on top and never shows on the bar. Writing 10 GB at 150 MB/s takes 67 seconds, and a SATA SSD at 500 MB/s takes 20. An unpacking launcher adds several minutes after the bar reads 100 percent.

One socket and one server can double a 13 minute wait

A single TCP connection rarely fills a 100 Mbps line for 13 minutes. Holding 100 Mbps across a 40 ms round trip needs 500 KB of data in flight, and some hosts and proxies cap the window far below that. Many content networks also limit one session to about 10 MB/s, which is 80 Mbps.

That 10 MB/s cap turns 800 seconds into 1,000 seconds, or 16 minutes 40 seconds, while 20 percent of the line sits idle. A 5 MB/s cap doubles the job to 2,000 seconds, or 33 minutes 20 seconds, and that is the usual explanation behind a complaint about a slow connection. The line is fine. The connection is capped.

Parallel connections are the workaround, and on a 10 GB file they earn their keep. Steam, most game launchers and every browser open several sessions, and a manager that splits a file into 8 parts uses the whole line where one stream used 80 percent. The limit then moves to the server and the disk, where more speed stops helping.

Wi-Fi delivers 50 to 70 percent, so the radio becomes the limit

The number on the bill describes the wire to the house, not the air in the room. A Wi-Fi link delivers 50 to 70 percent of its nominal rate once contention, retries and the half-duplex radio are counted. On a 100 Mbps plan that is 50 to 70 Mbps at the laptop, so the file takes 19 to 27 minutes.

A 2.4 GHz network on a 20 MHz channel with one stream has a 72 Mbps physical rate and hands a real client 35 to 50 Mbps. A 5 GHz network with 80 MHz and two streams has an 867 Mbps rate and delivers 400 to 500, far more than a 100 Mbps plan can use.

The test takes two minutes. Run the same download beside the router on a cable, then again on Wi-Fi where the laptop sits. If the cable run lands near 13 minutes and the Wi-Fi run near 26, the plan is delivering and the radio is not. Move the access point or run a cable, and the second number improves without a call to the provider.

The FCC 100/20 benchmark, a 1.2 TB cap and the 45 GB hour

One hundred megabits down is the current floor rather than a fast tier. In 2024 the FCC raised the fixed benchmark for advanced telecommunications capability from 25/3 Mbps to 100/20 Mbps and set a long term goal of 1 Gbps down and 500 Mbps up, in the 2024 Section 706 report. A 10 GB download is the kind of job that benchmark was written for.

Upload is the half that surprises people. The same 10 GB leaving the house at 20 Mbps takes 4,000 seconds, or 1 hour 6 minutes 40 seconds, five times the download time. A phone backup runs on that clock. Cable often pairs 100 Mbps down with 10 or 20 up.

Data caps turn the arithmetic into a budget. A saturated 100 Mbps line moves 45 GB an hour, so a 1.2 TB allowance covers 26 hours 40 minutes of flat-out transfer, or 120 files of 10 GB.

The FCC broadband speed guide puts one 4K stream at 25 Mbps. Four of them take the line and leave nothing for the download, so 13 minutes becomes 26 when the house is busy. That is a scheduling problem, not a bandwidth shortfall.