How Long to Download 1 GB at 200 Mbps

Forty seconds, and a transfer panel reading 25.0 MB/s

Take a 1 GB installer off a 200 Mbps line and the arithmetic is short. Two hundred megabits cross the interface every second. The file holds 1,000 megabytes, eight bits to the byte, so 8,000 megabits of payload. Divide by 200 and the clock ends at 40 seconds.

Meanwhile the panel in the corner of the display reports 25.0 MB/s. That is not a shortfall of 175 units. It is the same rate written in bytes, and the division by eight is a change of unit rather than a loss. Almost every argument with a support line about a new fiber package starts here.

The common error runs the division the wrong way round. A thousand megabytes divided by two hundred looks like five seconds, and the divisor is in megabits while the dividend is in megabytes. Multiply the file by eight first, or divide the rate by eight first, and the two units line up. Mixing them inside one sum is what produces a forecast that is wrong by a factor of eight.

Forty seconds is short enough that the access link is rarely the constraint for the whole span. The first fraction goes to DNS lookup, the TCP handshake and a TLS negotiation. The last goes to the disk and to whatever checksum the client runs. The middle belongs to the host, and on this tier the host is frequently the slowest part of the chain.

Where the 200 on the bill comes from

A 200 Mbps tier is the middle of the fiber catalogue, and the technology behind it decides how close to 200 a single transfer gets. Fiber to the home arrives on a GPON port with 2.488 Gbps downstream and 1.244 Gbps upstream, split across as many as 32 premises, or on an XGS-PON port with 10 Gbps each way. The optical network terminal on the wall converts that to Ethernet, and the carrier shapes the subscriber to a profile. On cable, a DOCSIS 3.1 modem bonds dozens of downstream channels and the same profile logic applies at the CMTS.

Profiles are usually built a little above the advertised number. A service sold as 200 Mbps often runs at 210 to 220, with the extra headroom covering framing so that a measurement reports the figure on the bill. At 220 the gigabyte lands in 36 seconds, and a 100 GB install in 1 hour 36 seconds rather than 1 hour 6 minutes 40 seconds.

The upstream half varies more than the downstream half. GPON splits its 1.244 Gbps return path, DOCSIS 3.1 still provisions many residential return paths at 20 to 50 Mbps, and symmetric fiber hands 200 Mbps in both directions. A gigabyte leaving the house takes 40 seconds in the last case and 6 minutes 40 seconds at 20 Mbps up.

One unit note belongs here. A gibibyte, 1,073.741824 megabytes, pushes the same transfer to 42.95 seconds, and Windows will report a 1 GB file as 0.93 GB because it counts in binary while printing decimal letters. The decimal prefixes are the SI set that NIST publishes, while the binary ones are an IEC addition from 1998. On one file the difference is 3 seconds. On a 500 GiB archive it is 24 minutes 35 seconds, so decide which unit a backup tool means before quoting a finish time.

Six file sizes, from a patch to a 100 GB install

The formula scales without modification, so the same line covers a security patch and a modern game. The right hand column applies 5 percent of framing and retransmission loss, near the top of the 3 to 5 percent range.

Two items repay a closer look. The 4 GB update lands in under three minutes, which is quicker than the average browser takes to draw a progress bar smoothly. The 100 GB install runs 1 hour 10 minutes, and the transfer is only half the story. A SATA SSD writing at 500 MB/s requires 3 minutes 20 seconds for the bytes alone, and decompression on a mid range processor usually adds 8 to 15 minutes. An NVMe drive writing at 3 GB/s cuts the write to 33 seconds, then waits on the same processor.

Video sizes follow from bitrate rather than from a fixed file size, which makes the same arithmetic useful in reverse. A 1 GB file holds 8,000 megabits, so at an 8 Mbps encoding it is 1,000 seconds of footage, or 16 minutes 40 seconds. At the 25 Mbps the FCC associates with 4K, the same gigabyte is 320 seconds, or 5 minutes 20 seconds. A two hour 4K film at that rate runs about 22.5 GB, and this line requires 15 minutes for it.

Compression changes the volume before the link sees it. A 100 GB game install is mostly textures, audio and video that arrived compressed from the studio, so a zip or 7z container saves a few percent at most. A 100 GB database dump or log bundle behaves the other way: gzip or zstd can take it to 15 GB, and the transfer drops from 1 hour 6 minutes 40 seconds to 10 minutes. Patch systems exploit the same idea with delta encoding, sending only the blocks that changed, which is why a 30 GB title can ship a 400 MB update.

At the small end the payload stops mattering. A 100 MB patch is 4 seconds of transfer wrapped in a second or two of DNS, handshake and first byte delay. Below roughly 20 MB, round trip time sets the pace and bandwidth barely enters the result. That is why a gallery of 40 thumbnails can feel slower on a 200 Mbps fiber line than one 2 GB video does.

A single socket rarely fills the pipe

TCP keeps unacknowledged data in flight, bounded by the receive window. Holding 200 Mbps open across a 40 ms round trip requires 1 MB outstanding at the sender; at 80 ms it requires 2 MB. Modern stacks scale the window upward, but plenty of hosts, proxies and middleboxes cap it far lower, and the flow levels off at a fraction of the package.

Congestion control sets a second ceiling. CUBIC, the default on most Linux hosts, probes for capacity and retreats on loss. BBR estimates the pipe instead and holds a higher rate over a lossy path. A policer that discards bursts can pin one CUBIC flow near 8 to 12 MB/s while 25 MB/s stays available on the same link.

The distributor sets a third. Several content networks cap one session at about 10 MB/s, which is 80 Mbps. A single socket then requires 1 minute 40 seconds for the gigabyte while 60 percent of the line idles. Steam, Battle.net and most update clients open many sessions for this reason, and so does aria2c with its split option or curl with parallel range requests. The speed measurement in a browser also opens several.

Framing adds a small, measurable slice. A 1,500 byte IP packet delivers 1,460 bytes of TCP payload after 20 bytes of IP header and 20 of TCP header, and Ethernet attaches 18 more bytes of header and checksum. That is 58 bytes of envelope around 1,460 bytes of content, or 3.97 percent, which is where the bottom of the 3 to 5 percent allowance comes from. PPPoE adds 8 bytes, a VPN tunnel 40 to 60, and a stream of small packets a far poorer ratio.

Receive buffers belong to the same story. A desktop OS autotunes the window upward as a flow proves it can use the space, but a small embedded device, an old NAS or a container with a trimmed kernel may hold a fixed buffer of 128 KB. At 40 ms that ceiling is 26 Mbps no matter what the line offers. Raising the buffer helps only when the path is clean; on a lossy link a bigger window just parks more data in a queue that keeps dropping it.

Protocol choice shifts the ceiling without touching the package. HTTP/3 runs over QUIC on UDP, keeps congestion control per stream, and avoids the head of line blocking that one lost TCP segment imposes on every multiplexed request. On a clean path the difference is small. On a path that drops 0.5 percent of packets, an HTTP/3 transfer can finish well ahead of an HTTP/2 one because a single loss does not stall the other streams. None of this raises the line rate; it decides how much of the line a single application can claim.

Measurements worth taking before buying anything: iperf3 with the parallel flag against a nearby host, which shows what several streams can do; a single stream run of the same measurement, which shows the per flow ceiling; and the socket statistics that print the congestion window and retransmit count. If the parallel run reaches 200 Mbps and the single run stalls near 80, the infrastructure is healthy and the host or the path is shaping one flow.

A 100 Mbps LAN port is the blunt version of the same failure. Connect a 200 Mbps service to a router with Fast Ethernet ports and the link negotiates 100 Mbps, carries about 94, and requires 1 minute 25 seconds for the gigabyte.

Radio, cable and the port on the wall

Wi-Fi is where a 200 Mbps package most often evaporates. A 2.4 GHz network on a 20 MHz channel with one spatial stream runs a 72 Mbps physical rate and hands a real client 35 to 50 Mbps after contention, retries and framing. The gigabyte then requires 2 minutes 40 seconds to 3 minutes 49 seconds. The same router on 5 GHz with 80 MHz and two streams has an 867 Mbps physical rate and delivers 400 to 500, more than the service can consume.

Channel width is the lever, and it has a price. A 160 MHz channel overlaps the radar bands that force DFS checks, and wide channels in an apartment block collect every neighbor in range. OFDMA and MU-MIMO in Wi-Fi 6 help when many devices compete for airtime. Neither raises the ceiling for one laptop in an uncongested room.

Newer radios widen the options and complicate the advice. The 6 GHz band arrived with Wi-Fi 6E and carries 160 MHz channels without radar checks, which suits a short range link in one room. Wi-Fi 7 adds multi link operation, bonding a 5 GHz and a 6 GHz radio to one client, and that helps a single laptop more than MU-MIMO ever did. A mesh system spends half its airtime on the backhaul unless it has a dedicated radio, so a second node in a far bedroom can cut the rate at the main node. Coaxial cable already in the wall can carry 2.5 Gbps through MoCA adapters, which beats most powerline kits by a wide margin.

Copper quality matters less than the marketing suggests. Cat5e carries a gigabit for 100 meters, which is four times what this tier requires. A crushed pair, a long flat patch cable or a worn jack is the standard reason a wired link negotiates 100 Mbps and holds the whole house to 94. Swap the cable before buying a router.

Signal numbers explain the rest. A laptop reporting a strong icon can still be running at a low modulation rate because the signal to noise ratio is poor, and the driver will not show that in the menu bar. A channel scan lists how many neighbors share the channel, and a retry counter climbing into the millions points at interference rather than distance. Move the access point off the floor, keep it out of a metal cabinet, and give it a band that the microwave and the doorbell do not use. None of that raises the line rate, and all of it lets the line rate arrive at the client.

The two minute measurement that identifies the culprit: run a speed measurement standing beside the router, then run it again where the slow device lies, then once with a cable. If the first number approaches 200 and the second lies near 40, the service is delivering and the radio is not. If all three read 94, a port or a cable is the cap. If all three read 210, nothing is wrong and the download was limited at the far end.

Four 4K streams, a call and a download at once

Capacity first. A saturated 200 Mbps link shifts 90 GB in an hour, 720 GB across an eight hour working day and 2.16 TB in a day. A 1.2 TB monthly allowance survives 13 hours 20 minutes at that pace, which is one long weekend of game installs rather than a month of browsing.

Concurrency is the more useful frame. The FCC speed guide puts one 4K stream at 25 Mbps. Four of them consume 100 Mbps, an HD call adds about 6, and 94 Mbps remains, or 11.75 MB/s. A 4 GB update then takes 5 minutes 40 seconds instead of 2 minutes 40, and nothing stalls. That is a reasonable picture of a family of four on this tier.

A device budget makes the same point without arithmetic in the head. The FCC household guide sorts light and heavy use by device count, and its companion chart gives 25 Mbps to a 4K television, 5 to high definition, about 4 to a 1080p conference call, 10 to a console downloading an update, and under 1 to music streaming. Four users on four displays can sit inside 150 Mbps and leave 50 for a console patch. Add a second console and a 4K upload of a phone backup and the same link starts dropping frames, not because 200 is thin but because the evening peak stacks every demand at once.

The failure mode here is latency rather than throughput. A download that fills the link also fills the router queue, and a video call waits behind it. Round trip time can climb from 15 ms to 300 ms without a single packet lost, and the call breaks into robot speech. Bufferbloat is the name for the pattern. Smart queue management on the router, in the form of cake or fq_codel, keeps the queue short and the call clean. The cruder fix is a client speed limit near 170 Mbps, which still lands the gigabyte in 47 seconds.

Cable upstream is the tightest part of the picture. DOCSIS 3.1 moved downstream to 1 Gbps and beyond years ago, while the return path on many packages still runs 20 to 50 Mbps, shared across the neighborhood node. Low latency DOCSIS exists and is deployed in some markets, but the queue on the return path is the reason a backup can make a call stutter. Fiber avoids the split in the other direction: a GPON port feeds up to 32 or 64 premises, and an XGS-PON port carries 10 Gbps each way, so contention only appears when several neighbors saturate at once.

Upstream deserves its own paragraph. A coax package badged 200 Mbps often pairs with 20 Mbps upstream, so the gigabyte takes 6 minutes 40 seconds to leave the house and a 50 GB offsite backup takes 5 hours 33 minutes. Fiber to the home is usually symmetric, and a GPON splitter shares 1.244 Gbps of upstream among its households, which is ample until several neighbors seed at once. If the household sends video, that upload number matters more than the download headline.

Why a speed test reads 210 and a download reads 12

Operators commonly provision a little above the advertised rate, often near 10 percent, so a 200 Mbps service measures 210 to 220 on an uncongested line. At 220 the gigabyte lands in 36 seconds rather than 40, and a 100 GB install in 1 hour 36 seconds.

A speed measurement flatters the link in three ways. It picks a nearby host, it opens several parallel streams, and it samples the moment when TCP has just reached full window. A browser download gets one stream, a distant origin and a file sitting behind a delivery node that may be having a bad evening. The distance between 220 and 12 is not a lie in either direction. The two measurements answer different questions.

Peering explains the evening slump. When a transit link or an interconnection point saturates between 8 and 11 pm, every subscriber behind that path sees the same reduction, and a measurement at 7 am will not reproduce it. A VPN can help by moving the path, and can hurt by adding a hop and an encryption cost.

A route trace separates the two explanations for a slow evening. If latency climbs at the first hop past the router, the access link or the carrier's aggregation is congested. If it climbs eight hops out, the problem lies at a peering point or inside the destination infrastructure, and no package change at home will fix it. Loss that appears at one hop and persists to the end is usually a congested queue; loss at the final hop only is usually the host. Most large content networks answer from an anycast address, so the same hostname can take a different path from one hour to the next.

Deliberate shaping looks different from congestion, and the two get blamed for each other. Congestion worsens in the evening and improves at 6 am; shaping holds a steady ceiling at every hour, often on one protocol or one port. Test the same file over a VPN and again without it: if the tunnel is faster, a policy was holding the plain flow back. Test a large HTTP file and a large HTTPS file from the same host; a wide gap points at protocol specific handling rather than a thin pipe. None of these measurements requires a support ticket, and each one produces a number a carrier can act on.

What a carrier can see is narrower than subscribers assume. A classifier inspects packet headers, port numbers, the host address and the first bytes of a flow, then places the flow in a queue or a policer with a token bucket. Encrypted traffic hides the payload but not the destination, so a video service and a file host remain distinguishable by address. That is why shaping tends to hit one service at a time, and why a different mirror or a different protocol can dodge a policy that a package upgrade would not.

Diagnose in four steps: a wired measurement to a nearby host, a second measurement to a distant one, a multi session download of a large Linux image, then the same file over Wi-Fi beside the router. The weakest of the four names the bottleneck, and only one of them is the package.

Provisioning also explains the odd number on the bill. A 200 Mbps profile may be built as 220 with headroom for overhead, or as 200 with the rate shaped at the modem. Neither is a scam. Ask the carrier what the profile is, then compare like with like.

Filling a 2 TB drive at 90 GB an hour

Capacity math is where this tier shows its teeth. Ninety gigabytes an hour means a 500 GB Steam library takes 5 hours 33 minutes to fetch again after a clean install, a 1 TB drive fills in 11 hours 6 minutes 40 seconds, and a 2 TB drive fills in 22 hours 13 minutes 20 seconds. A 4 TB drive requires 44 hours 26 minutes 40 seconds of continuous transfer, which is longer than most users leave a machine running.

Monthly allowances land in the same territory. A 1.2 TB cap covers 13 hours 20 minutes of saturated use, a 2 TB cap 22 hours 13 minutes, and a household that installs two large games a month plus a few updates will use a third of either without streaming anything unusual. Uploads count against the same allowance on most cable packages.

Two habits keep a cap intact without slowing anything down. Schedule large installs after midnight if the carrier offers an off peak window, and pause cloud sync during a game download so the same bytes do not cross the link twice. Neither changes the rate; both change the monthly total.

The tier still fits a household that installs a large title a couple of times a month, runs 4K on several displays and works from home on video. It does not require a 2.5 Gbps port, Cat6a cabling or a Wi-Fi 7 router. It does require 5 GHz coverage where the notebook sits, a gateway without 100 Mbps ports and sufficient upstream for backups. A home lab pulling container images all day, or a shared house where four users install games on one evening, wants symmetric fiber instead.