How do you test internet speed correctly for telephony?

What a speed test measures

A speed test is a website or app that sends and receives a large amount of data to and from a test server, and measures how fast it went. The result is usually shown in three numbers:

• Download — how many megabits per second reach you. This is the number that appears in advertisements.
• Upload — how many megabits per second leave you. Usually much smaller than the download.
• Ping — how long it takes a small packet to reach the test server and come back.

Advanced tests show two more numbers: jitter — how much the ping varies, and latency under load — what happens to the ping while the line is busy with a download or upload. For telephony, these two are almost more important than the rest.

Why download matters least for calls

A phone call uses very little: with the common G.711 codec, about 100 kilobits per second in each direction — a tenth of a megabit. A 100 Mbps download line and a 1,000 Mbps download line will give exactly the same call quality, because both are very far from the limit.

What does matter is the upload. Your voice goes out through it, and it is usually the narrow side of the plan. In many plans the upload is a tenth of the download or less, and every cloud backup or file you send fills it.

And most important: stability. A call is sensitive to short moments of load, not to the average. A line that gives 50 Mbps most of the time but "freezes" for a second every few minutes will sound worse than a stable 10 Mbps line.

In other words: for telephony you don't need a "fast" line, you need a quiet and stable one. An office of 15 employees usually handles only a few simultaneous calls, which is very little compared with any modern plan. What does run out quickly is the customer's patience when the voice cuts out, and speed doesn't help there.

Latency under load: the test most people miss

Most speed tests measure ping just before they start downloading, when the line is quiet. That is the "good" ping. The important question is what happens to the ping when someone in the office downloads or uploads a large file, because that is the situation in which calls really happen.

In many routers, when the line fills up, they hold a long queue of packets in memory. The call's packets wait at the end of the queue, and the ping jumps from 20 to 300 or even 1,000 ms. This phenomenon is called Bufferbloat — a "bloated queue."

Modern speed tests show this separately, under names like "Loaded latency," "Latency during download" and "Latency during upload." If the difference between the quiet ping and the ping under load is larger than a few dozen milliseconds, calls will suffer every time someone loads the line.

The solution is usually not in the line but in the router: a QoS setting that gives priority to calls, or limiting the speed in the router slightly below the line speed, so that the queue stays in your router and not at the provider.

How to test correctly, step by step

1. A computer on a cable. A test over Wi-Fi measures the Wi-Fi, not the line.
2. Close whatever is running. Updates, backups and videos on the testing computer distort the result.
3. Several times, at several hours. In the morning, at noon and at the office's peak hour. One result is not a picture.
4. Look at the upload, the jitter and the latency under load, not only at the download.
5. Also run a continuous ping for a few minutes, to see jumps and packet loss that a short speed test won't catch.
6. Write it down. The time, the results, and from which computer. That way you can compare and show the provider.

Common mistakes

• A test from a mobile phone on Wi-Fi. The result is affected by the distance to the router, by walls and by the device itself.
• Judging only by the download. 500 Mbps download says nothing about the upload or about stability.
• A test at a quiet moment. At eight in the morning, before everyone has arrived, every line looks excellent.
• A test server on the other side of the world. Or, the opposite, only the internet provider's own server, which is very close and gives an optimistic result. It is worth testing against two or three different servers.
• An open VPN. The test goes through the VPN server and measures it.
• A conclusion from one test. Call problems are usually intermittent. One normal test doesn't prove that the line is fine.

How to read the result

Here is an example of a result from an office of eight employees, and how to interpret each row in the context of calls:

In this case the line is "fast" by any standard, and still complaints are possible. The last row shows why: when the upload fills up, the ping jumps thirty times higher. The solution is QoS in the router, not a faster line.

Reference numbers for telephony

These are common figures for a general estimate, not a binding standard. How much upload you need depends on the number of simultaneous calls, and is explained in the article on network capacity.

The speed you pay for versus the speed you get

The speed in a plan is usually "up to." In practice you get less, and at peak hours in the neighborhood sometimes much less. In addition, in many plans sold as "100 Mbps" the upload is only a few Mbps, and that is the number that determines calls.

Before ordering a line for an office with telephony, it is worth asking the internet provider explicitly what the upload speed is, and not settling for the big number. On fiber lines (optical fiber) the upload is usually much higher and sometimes equal to the download, which is a noticeable advantage for an office that talks a lot.

A field example: "the 1,000 Mbps line"

A chesed organization called "Or Shlomo" (a made-up name) upgraded its line to 1,000 Mbps download, hoping that the "robotic" voice in calls would disappear. It did not disappear.

A correct test, with a computer on a cable, at a busy hour, with latency under load, showed that the upload was fine, but the jitter from the computers sitting on Wi-Fi reached 80 ms. The phones themselves were connected through a Wi-Fi extender on the second floor. Moving to cables solved the problem. The investment in the fast line was not needed for calls at all.

The lesson: a speed test is a diagnostic tool, not a grade. It helps you understand where the problem is only when you test correctly.

Internal test versus line test

A regular speed test measures the whole path: the computer, the cable or Wi-Fi, the switch, the router, the provider's line and the test server. When the result is poor, it doesn't say in which part of the path the problem is.

To separate them, you compare situations: the same test from a computer on a cable connected directly to the router, and then from the regular workstation. If the result is good next to the router and poor at the workstation, the problem is in the cable, the switch or the Wi-Fi on the way. If the result is poor even next to the router, the problem is in the router or the line.

Many routers also have a built-in speed test in the management screen. It measures the line directly from the router, without the internal network at all, and this is a good way to isolate the line.

Tests that suit telephony especially

There are tools that test specifically what a call needs: they send a stream of small packets, like voice, for a few dozen seconds, and measure jitter, packet loss and an estimated quality score. This score is usually called MOS (Mean Opinion Score), on a scale of 1 to 5. Above 4 is considered very good quality.

The advantage of such tests is that they resemble a real call: small, steady packets, and not one big download. The disadvantage is that they measure against their own test server, not against the PBX itself.

The most realistic test is still a trial call: a call of a few minutes to a mobile phone, at a busy hour, from a phone connected the way all the phones are connected. If it sounds good in both directions, that is what counts.

What to bring to your internet provider

When the problem is in the line, the internet provider will usually ask to run a test while you are on the phone with them, and it will usually come out fine, because the problem is intermittent. So come prepared:

• A table of tests from several days and hours, from a computer on a cable connected directly to the router.
• The result of a continuous ping over a few minutes, with the packet loss percentage and the maximum time.
• The result of a tracert that shows at which hop the time jumps.
• An exact description: at what time, for how long, and what is heard, by them or by us.

With data like this it is easier to reach a technician who understands the problem, and not just the request to "restart the router."