The Slow Upload That Wasn't the Internet
Northgate Imaging runs a small radiology office with a 200 Mbps symmetric fiber circuit. Technicians upload 25 MB scan bundles to a regional archive; on a typical day they send about 12 bundles per hour during a 6-hour window. The office manager reports that each upload takes roughly 30 seconds and blames the 'slow internet.' A vendor has quoted a 500 Mbps upgrade at $900/month. Before signing, the IT generalist is asked to check the numbers and to explain the difference between the circuit's rated speed and what users actually experience.
1. Calculate the bandwidth the upload workflow actually consumes and decide whether the 500 Mbps upgrade would fix the 30-second uploads. Show the arithmetic.
Read the worked answer
Convert units first. The circuit is rated in megabits; the files are in megabytes.
- 25 MB × 8 bits/byte = 200 Mbit per bundle
- Observed: 200 Mbit in 30 s → ≈6.7 Mbps per upload stream
Total load. 12 bundles/hour × 6 hours = 72 bundles/day → 72 × 200 Mbit = 14,400 Mbit over 21,600 s → ≈0.67 Mbps average.
Worst case. Even if all 12 bundles in an hour transferred simultaneously: 12 × 6.7 Mbps ≈ 80 Mbps, which is about 40% of a 200 Mbps symmetric circuit.
Conclusion. The circuit is not the bottleneck. Upgrading to 500 Mbps raises the ceiling but changes nothing about a transfer already running at 6.7 Mbps - the observed per-file rate would stay roughly the same. Something in the path is capping the transfer: workstation disk or antivirus scanning, TLS/encryption overhead on an old client, a proxy or firewall doing content inspection, server-side rate limiting, or a slow Wi-Fi link to the technician's cart. The correct next step is a wired throughput test to a known-good endpoint at different times of day, plus checking the upload client and the archive vendor's limits - not a $900/month circuit.
2. The manager says, 'I watched the progress window and it never went above 3. If we have 200, why am I only getting 3?' Explain what is going on and what number she is actually reading.
Read the worked answer
She is comparing two different units.
- Circuit speed is quoted in megabits per second (Mbps) - decimal, 1 Mbps = 1,000,000 bits/s.
- File-transfer dialogs typically display megabytes per second (MB/s) - 1 MB/s = 8 Mbps.
So 200 Mbps ÷ 8 = 25 MB/s theoretical, or roughly 22 MB/s after TCP/TLS overhead. And '3' in a transfer window, if it is MB/s, is actually 24 Mbps - not 3 Mbps.
Either way the comparison is meaningless in the abstract: the 6.7 Mbps measured from the 25 MB/30 s observation is about 0.83 MB/s, roughly 3% of the circuit. The point to make is that a rated speed is a ceiling, not a prediction, and that bits-vs-bytes (and decimal prefixes) are the most common source of 'the internet is slow' tickets. Ask her for the units shown in the window before drawing any conclusion.
3. The vendor's quote says 'up to 500 Mbps.' What should the generalist establish before treating that as a 2.5× improvement?
Read the worked answer
Rated speed is the least interesting number in the quote. Ask:
- Symmetry - is the 500 Mbps upload as well as download? A 500/20 circuit would be worse for this workflow than the current 200/200.
- Dedicated vs. shared - is 500 Mbps a committed rate or a contended best-effort figure that collapses at peak?
- SLA and credits - what availability is guaranteed, and what is actually credited when it is missed?
- Term and exit - contract length and early-termination cost, especially since the evidence suggests no upgrade is needed.
- Delivery method and CPE - new hardware, installation fees, new public IPs that may need allowlisting with the archive vendor.
- Baseline first - verify what the current circuit actually delivers on a wired test, at peak and off-peak, before buying more of it.
The judgment: a capacity purchase should follow a measurement showing capacity is the constraint. Here the measurement shows it is not, so the honest recommendation is to decline or defer and spend the money on diagnosing the client-side bottleneck.