How long to download 20 GB at 10 Mbps

Twenty gigabytes at 10 Mbps is 16,000 seconds, four hours twenty six minutes forty

A rate of 1.25 MB per second, counted out

Twenty gigabytes is 20,000 MB, and at eight bits to a byte that is 160,000 megabits. A 10 Mbps line carries 10,000,000 bits each second, so 160,000,000,000 / 10,000,000 = 16,000 seconds. Sixteen thousand seconds is 4 hours 26 minutes 40 seconds, and it is the number every other paragraph here works from.

The byte view gives the same answer with a figure that is easier to watch on a progress bar. Ten megabits a second is 10 / 8 = 1.25 MB/s, and 20,000 / 1.25 = 16,000. At that pace a minute adds 75 MB, an hour adds 4.5 GB, and the whole file occupies most of an evening.

Every gigabyte costs 800 seconds on this line, which is 13 minutes 20 seconds. That single figure scales: 5 GB is 4,000 seconds, 50 GB is 40,000 seconds, and 100 GB is 80,000 seconds, or 22 hours 13 minutes 20 seconds. Nothing about the file changes the arithmetic, only its size.

A Windows file manager will call the same download 18.6 GiB, since it counts 1,073,741,824 byte units, and the NIST binary prefix page keeps those units distinct from the decimal ones used here. The extra 7.37 percent is a change of unit rather than a slower line, and the clock moves to 17,179.87 seconds, or 4:46:20.

Six percent of framing and retransmission overhead turns 16,000 into 16,960 seconds, which is 4 hours 42 minutes 40 seconds. That is the figure to plan an evening around, because a plan that delivers its full label with no cost per packet does not exist.

The bar creeps 22.5 percent an hour

What the progress display can and cannot tell you

Dividing an hour by the total gives the rate of progress: 3,600 / 16,000 = 0.225, so the bar covers 22.5 percent every hour. Over a 4 hour 26 minute 40 second window that is a slow crawl, and the estimate a browser shows will drift because it is computed from the last few seconds rather than the whole file.

Anchor the schedule to percentages instead of the remaining-time display. If the transfer starts at 9:00 pm, a quarter is done at 10:06:40, half at 11:13:20, three quarters at 12:20:00, and the last byte lands at 1:26:40 the next morning.

Those clocks assume a flat 10 Mbps. Real transfer rates sag and recover, so the mid-point arrives late in most homes and the last ten percent can take twenty minutes on its own. A client that reports 1.25 MB/s steadily for twenty minutes has moved 1,500 MB, which is 7.5 percent of the file, and that is the way to judge whether the session is on track.

One habit saves confusion. Note the byte count at the start of an hour and again at the end, then divide by 3,600. A household that sees 4.2 GB instead of 4.5 GB has lost seven percent to contention or to the far server, and the projection moves from 4 hours 26 minutes to 4 hours 46 minutes without anything having broken.

An eight hour night holds one copy, not two

Sizing the window before starting

An overnight window of eight hours is 28,800 seconds. One copy of this file needs 16,000 of them and leaves 12,800 seconds, or 3 hours 33 minutes 20 seconds, unused. A second copy would need another 16,000, and 32,000 seconds is 3,200 seconds more than the night offers.

With overhead the totals move: one copy becomes 16,960 seconds, and two become 33,920, which fits inside a ten hour window with 2,080 seconds to spare rather than 4,000. The margin is thin enough that a restart late in the second copy pushes it past sunrise.

The practical rule is to start the job before the window opens rather than at bedtime. A transfer that begins at 9:00 pm and finishes at 1:26 am leaves the rest of the night free for a second job, a backup or a scheduled update, and it does not compete with the morning's video calls. Starting at midnight instead puts the finish at 4:26 am, which is fine until the machine decides to install updates at 3:00 am.

Sharing ten megabits: one 1080p stream doubles the wait

Contention on a line with no headroom

A 10 Mbps line has no spare capacity, so every other activity subtracts directly. Netflix lists 5 Mbps for 1080p and 3 Mbps for 720p on its recommended connection speed page. One 1080p stream takes half the line, leaving 5 Mbps, and the file then needs 32,000 seconds, or 8 hours 53 minutes 20 seconds.

Two high definition streams fill the line completely, and the download does not slow so much as stop. This is the situation where a router's queue matters: a long buffer keeps the video smooth while the file transfer starves, and the same buffer makes every page load feel broken for the duration.

The workable arrangement on this tier is a schedule rather than a setting. Run the file overnight and let the streams have the evening, or cap the download client at 8 Mbps and accept 20,000 seconds, which is 5 hours 33 minutes 20 seconds. A client-side cap is the only throttling a subscriber controls, and it keeps the household usable while the job continues.

A session that dies at 70 percent costs the last hour and twenty

Range requests and the price of starting over

A dropped connection is not the same as a lost evening, provided the client can resume. Most servers support range requests, the HTTP feature that lets a client ask for bytes from a given offset rather than from zero, and most download managers use it. When that works, a session that dies at 70 percent leaves 30 percent to fetch: 4,800 seconds, or 1 hour 20 minutes.

Resume depends on the server as much as the client. A host that answers a range request with the whole file forces a restart, and a signed URL that expires after an hour breaks a four and a half hour job by design. Game launchers and operating system updaters handle this themselves with chunked verification, which is why they resume reliably where a browser download sometimes does not.

Integrity is the other half. A file assembled from several partial sessions can be corrupt if one segment came from a different build, so check the published hash when the download finishes. On a line this slow, discovering a bad file after 16,000 seconds is the worst outcome available, and a checksum takes seconds to run.

What 20 GB costs on a metered hotspot

Allowances, overage and the 128 kbps floor

A 20 GB file is a serious event on a mobile plan. An FCC notice of inquiry on data caps released in 2024 describes the two mechanisms that follow an allowance: per gigabyte charges on some plans, and a hard speed cut on others, citing one prepaid carrier that drops downloads to a maximum of 128 kbps once the high speed allowance is spent. The notice is filed as FCC 24-136.

The speed cut is worse than the bill in one respect: it is not a delay, it is a different order of magnitude. At 128 kbps the same 160,000 megabits need 160,000 / 0.128 = 1,250,000 seconds, which is 14 days 11 hours 13 minutes 20 seconds. No amount of patience turns that into an overnight job, so the transfer has to wait for a new billing cycle or move to a fixed line.

Deprioritization is the third mechanism and the hardest to plan around. It applies during congestion rather than after a fixed volume, so a phone that has used 40 GB may run at a quarter of its usual rate at 8 pm and at full rate at 6 am. The FCC notice treats it as distinct from a cap, and for a 20 GB download the practical difference is whether the schedule can move to the quiet hours.

Sleep, heat and a radio that quits before the file does

Keeping the session alive for four and a half hours

A four and a half hour transfer outlives the defaults on most laptops. Sleep after 30 minutes of no input suspends the network stack, and the download resumes whenever the lid opens, sometimes at a fifth of the speed while the radio renegotiates. Setting the machine to stay awake for the duration is the first job, and it is a power setting rather than a download setting.

Power draw is modest but not zero. A laptop pulling 15 W for 4 hours 26 minutes 40 seconds uses 66.7 watt hours, which is most of a small battery, so a machine on battery alone will not finish this job. A phone used as a hotspot is worse off: the radio runs continuously, the case warms up, and thermal management cuts transmit power or drops the link after an hour or two in a warm room.

The band matters on this tier less than on a fast one, since 10 Mbps is well below what either band can carry. What matters is stability. A 2.4 GHz link reaches further and survives walls, and its congestion comes from neighbours rather than distance. A 5 GHz link is cleaner but drops out at the far end of a house. For an overnight job, the band that stays associated for eight hours wins over the band with the higher peak.

Wired is the right answer where it exists. A single Ethernet cable removes the radio, the thermal problem and the renegotiation, and it costs less than a month of the subscription. On a line this slow the cable is not about speed at all, it is about not losing 16,000 seconds to a dropped association at 3 am.

Mailing a drive wins above 81 gigabytes

Where the wire stops being the cheapest route

At 1.25 MB/s the arithmetic eventually favours a courier. In an 18 hour overnight delivery window the line moves 64,800 seconds x 1.25 MB/s = 81,000 MB, or 81 GB. Below that size the network wins because it is already there. Above it, a box with a drive inside arrives sooner than the bytes do.

What a slow line cannot fix is the shape of a working day. A 20 GB file that arrives at 1:26 am is usable at breakfast, and that is the whole argument for scheduling rather than upgrading. The upgrade argument starts when the same file has to arrive twice a week, because two nights of a four and a half hour job is a standing commitment rather than an inconvenience.