Bandwidth and internet speed
A line sold as 20 megabits per second shows 2.5 megabytes per second in the download bar, because a byte is eight bits and getting from the contract number to the number on your screen means dividing by eight. And bandwidth is not the only number in play: latency, the time a packet takes to go and come back, is a separate figure and for most everyday work it decides whether things feel slow more than bandwidth does.
- Lesson 11 of 12
- Beginner
- Free, no signup
One line, two units, and a division by eight
The column is in megabits per second, the unit the line is sold in.
- 20 megabits per seconda 1000 MB file: 400 seconds, close to seven minutes
- 50 megabits per secondtwo and a half times the one above, the conversion being linear
- 100 megabits per secondthe contract ceiling, not what always arrives
This conversion is arithmetic only and shows the ceiling. The real figure is always a little lower, because part of the capacity goes to the protocols themselves.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
Why does the download number differ from the one you bought?
Because they are two different units written to look alike. Internet services sell in bits and computers show file sizes in bytes, and a byte is eight bits. The small and capital letter is the only thing separating them in writing: Mbps is megabits and MB/s is megabytes.
So the conversion is one simple division, and this single number clears up most of the misunderstanding:
| What you buy | What you see in the download bar |
|---|---|
| 20 megabits per second | 2.5 megabytes per second |
| 50 megabits per second | 6.25 megabytes per second |
| 100 megabits per second | 12.5 megabytes per second |
With that table you can answer the how long will it take question yourself. A 1000 megabyte file on a 20 megabit line takes 400 seconds in the best possible case; that is close to seven minutes, and only when nothing else is using the line.
One thing written in the contract and rarely read: that number is a ceiling, not a commitment. The word up to sitting beside it says exactly that. Part of the capacity also goes to the protocols themselves and never reaches your data, so even in the best conditions the real figure sits a little below the ceiling.
Bandwidth or latency: which one is your problem?
One analogy that genuinely works: bandwidth is the width of the road and latency is its length. A wider road means more cars pass at once; a shorter road means each car arrives sooner. The two have nothing to do with each other and you can have one without the other.
The symptoms are separate too, which makes the diagnosis easy. If a large file download drags, if a 4K video keeps dropping its quality, or if everything falls apart when three people work at once, the problem is bandwidth. But if pages are slow to start opening, if a video call breaks up, or if everything in a game happens a beat late, the problem is latency and buying more bandwidth solves none of it.
One measurement from our own site makes this clear. We fetched the front page of rgb.ir compressed at 44,916 bytes, about 44 kilobytes. The whole thing took 63 milliseconds, and 54 of those went by before the first byte arrived. So the data transfer itself was about 9 milliseconds of that 63, and the rest was waiting.
Now do the arithmetic: double the bandwidth and those 9 milliseconds become 4.5 and the total goes from 63 to 58. But if the server is one round trip further away, that single round trip alone can add a hundred milliseconds. For small pages, which is most of the web, distance matters more than the width of the road.
Two different numbers, two different sets of symptoms
Bandwidth: the width of the road
- A large file download drags on
- A high quality video keeps dropping its quality
- Everything falls apart when three people work at once
- A cloud backup does not finish overnight
- Buying a bigger package genuinely answers here
Latency: the length of the road
- Pages are slow to start opening
- A video call breaks up
- In a game everything happens a beat late
- A foreign site is slow while a local one is fast
- Buying a bigger package changes nothing here
One line can have both problems at once. If you see symptoms from both columns, check latency first, because it is cheaper to diagnose.
Why does every speed test give a different number?
Because a speed test does not measure your internet speed. It measures the speed of the path between you and one particular server, and the tool picks that server. Change the server and you change the answer.
We measured this on our own server so the size of the effect is visible. A 21 megabyte file, from one machine, within one minute, from three test servers at three distances. The first run:
| Test server | Round trip | Download speed |
|---|---|---|
| Helsinki, the same city | 0.3 ms | 284 MB/s |
| Nuremberg, Germany | 23.5 ms | 50 MB/s |
| Singapore | 188.7 ms | 7.1 MB/s |
The same line, the same moment, and a number that differs by forty times. In the unit the services sell in, that is roughly 2270 megabits down to 57 megabits. If we wanted to, we could show you any number we liked by choosing the server; that alone is reason enough not to trust a single test.
The technical reason is one thing: at any moment only a certain amount of data can be in flight, and until the acknowledgement comes back the sender waits. The longer the round trip, the longer that wait, and that is what lowers the practical ceiling. RFC 6349 calls this relationship the bandwidth delay product and makes it the basis of a correct test.
And an observation we did not expect. We measured three times in a row: the Singapore figure came out 7.07, 7.17 and 6.97, essentially steady. The Helsinki figure swung between 188 and 414 MB/s. The most distant test was the most repeatable, because there the latency sets the ceiling; the nearest test was unstable, because 21 megabytes finishes there in a fraction of a second and the measurement never gets time to settle.
Should I buy more bandwidth or not?
The honest answer comes out of one multiplication and one division, and the operator will not do it for you. Bandwidth only shortens the transfer part. If what bothers you is pages opening, that part was the 9 milliseconds out of 63 you saw in the second section, and doubling it saves five milliseconds, which is nothing you can feel.
But there are three cases where more bandwidth genuinely answers. First, when several people use one line at once; here the capacity really is divided and the road really is narrow. Second, when you move large files regularly, downloading or uploading. Third, when something streams continuously and keeps dropping its quality.
And one number that is always forgotten: upload. Most home packages carry far less upload than download, and upload is what makes a video call, a file upload and a cloud backup work. If your picture breaks up for other people in meetings while their picture is fine for you, the problem is your upload, not your download.
Where do you go for the number you need? To the service own page. Netflix publishes the recommended speed for each quality itself, and every other service has such a page. A number someone wrote in a forum or a language model produced is not a source.
How to measure it properly yourself
Five rules that turn a meaningless measurement into one you can cite. Measure on a cable and not on wifi, or you are measuring the radio and not the line. Quiet the other devices for those few minutes. Run it three times and look at the pattern, not at one number.
And two rules that are said less often and matter more. First: try both a near server and a distant one, because as you saw above the difference between them is itself a diagnosis; if near is good and far is bad, your line is healthy and the international route is expensive. Second: measure at two different times of day, one early morning and one at night, because capacity is shared and at night the same line gives a different number.
To see how long a real page takes and which part of it is waiting, the tool is already on your computer. This command prints the same four numbers we used in the second section:
curl -s -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n" https://example.ir/If ttfb is large and the gap from it to total is small, the problem is waiting and not bandwidth. If it is the other way round, the data transfer is heavy and there the page weight has the first word; that subject belongs elsewhere and we follow it in the site speed track.
The fast path, with AI
The ordinary way to handle my internet is slow is to run a speed test and show the number to the operator. The fast way is to take four numbers from a real page load and force the language model to say, from those four numbers alone, whether the problem is waiting or transfer. The difference is that the second way tells you whether buying a bigger package changes anything at all, which is the one thing no speed test tells you.
- Pick one local site and one foreign site that you open every day. Comparing those two is half the diagnosis.
- For each one run this and keep the raw output: <code>curl -s -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}" https://ADDRESS/</code>. If the command is not available, the same four numbers are in the Network tab of the browser developer tools.
- Repeat it three times and at two different times of day, one early morning and one at night. A single measurement proves nothing.
- Hand all the outputs together to a frontier class model and ask it only to classify: waiting or transfer, and whether more bandwidth would help.
Copy-ready recipe
You are a network specialist. Draw conclusions only from the numbers below and add no number from memory.
My internet package: {the figure and unit written in the contract}
Connection type while measuring: {cable / wifi}
Local site, three measurements in the morning:
{raw output}
Local site, three measurements at night:
{raw output}
Foreign site, three measurements in the morning:
{raw output}
Foreign site, three measurements at night:
{raw output}
What actually bothers me: {for example pages open slowly / downloads are slow / video calls break up}
Write four things:
1. For each group of measurements, say what share of total was waiting (up to ttfb) and what share was transfer (from ttfb to total). From these numbers only.
2. Based on those shares, which is the dominant problem: waiting or transfer.
3. Assuming the bandwidth doubles, how much shorter the transfer part gets and how much shorter the total gets. Give numbers.
4. Given what I said bothers me, whether buying a bigger package is reasonable. If the answer is no, write no plainly.
Rules: do not write any number from memory about the speed required for some activity; if one is needed, write that this number should be taken from that service own page. If the measurement was on wifi, say first that the figure also measured the radio and that any conclusion about the line is tentative.Before you trust the output: There are two places where the model slips easily and you must catch it. First the units: if it mixes megabits with megabytes anywhere, the whole of the third answer is wrong by a factor of eight; check your own numbers by hand once. Second the buying advice: most of the text models learned from ends at get a bigger package, because operator marketing is a large part of that text. If the third answer says doubling the bandwidth saves a few milliseconds and the fourth still says upgrade, trust the third.
AI in this kind of work
The subject of this lesson is arithmetic at heart, and that makes it one of the safest uses of a language model: you hand over raw numbers and ask it to take ratios and compare. It has a clear boundary too. The moment you ask the model for a figure about how much speed is needed, it switches from calculating to recalling, and that is where an unsourced number gets produced.
Tools that actually help
- Claude For handing over several raw timing outputs and getting the ratios and the comparison, the best pick on this list. Iran is not on Anthropic list of supported countries, so there is no official route to sign up or pay.
- Gemini For converting units and explaining the terms in Persian. Always check the simple arithmetic yourself once; a division by eight can be done on a phone calculator. Google own page says the Gemini app works in more than 230 countries and territories, and Iran is not on that list.
- Gemini Notebook Its modest but effective use here: upload your own internet contract and ask what exactly is committed and what is written with the words up to. The answer comes from the contract text and not from the model memory. It runs on a Google account, and Iran is not among the available regions.
Where it backfires
Three risks, and all three happen in this exact topic. First the units: models swap megabits and megabytes, and because both start with mega an answer that is wrong by a factor of eight looks entirely healthy. Second unsourced numbers: a question like how many megabits does a video call need gets an answer written with great confidence and quoted from nowhere; the right number is on that service own page, and Netflix is an example that publishes it itself. Third a bias toward buying: a large part of the text these models have seen is operator advertising, and the result is that the upgrade suggestion repeats even when the arithmetic says otherwise. And Anthropic itself calls this confident invention hallucination in its documentation and writes about reducing it, which means the vendor treats it as a real weakness. For what paying for these tools looks like from Iran, see the buying guide.
Sources: Netflix: recommended internet speeds Anthropic: reduce hallucinations Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
Let us state the most important boundary of this lesson at the top: our figures come from a server in a datacentre, and your home line does not produce them and is not meant to. What transfers is the shape of the story, that distance lowers the ceiling and the choice of server changes the answer; the size of the numbers does not transfer. Two more things we have not measured and are not in this lesson: how a shared line behaves at peak hour, which only a measurement on that line reveals, and mobile internet, where tower load and signal strength have the first word. And this lesson does not fix a line; what it does is tell you where the problem is, so the money goes to the right place.
From our own work
Every figure in this lesson was measured on our own server on 7 September 2026 and none of them was rounded in a flattering direction. We fetched our own front page with one request: compressed 44,916 bytes, first byte at 54 ms, total 63 ms; so the data transfer was about 9 ms of the total and the rest was waiting. Uncompressed the same page is 219,804 bytes, nearly five times as much, which itself shows how much compression takes off the bandwidth side. Then we fetched a 21 megabyte file from three distances within the same minute and repeated it three times. First run: Helsinki 284, Nuremberg 50, Singapore 7.1 MB/s. The other two runs showed which figure is trustworthy: Singapore stayed at 7.17 and 6.97, while Helsinki swung between 188 and 414. Round trips were measured with ten packets and we report the minimum rather than the average: 0.297, 23.494 and 188.695 ms.
Real follow-up questions
The speed test shows a high number but sites are slow to open. Why?
Because the speed test measures bandwidth and page opening depends mostly on latency. The test usually connects to the nearest server, where latency is low; the site that will not open may be on the other side of the world. Run the same test against a distant server and the number gets closer to reality.
Does upload matter, or only download?
Upload matters exactly where people do not expect it: video calls, file uploads and cloud backups. The clear sign is that your picture breaks up for other people in a meeting while their picture is fine for you. Most home packages carry far less upload than download, so check that figure separately in the contract.
Should I run the speed test on wifi or on a cable?
On a cable, if you want to measure the line. On wifi you are measuring the line and the radio together, and if the number comes out low you do not know which one is to blame. Do run it once on wifi as well and compare; the gap between the two numbers tells you how far the radio lags behind the line.