Unfortunately due to the generally poor state of Australia’s internet infrastructure (don’t get me started), testing your internet speed has become a bit of national obsession. We buy plans based on the speed of the connection and get grumpy if our provider doesn’t supply those speeds.
When you think about it this is a pretty crazy state of affairs and is really an indication that what we have probably isn’t enough. Compare that to Europe where most people have no idea how fast their connection is. “It’s fast enough for me”, said a friend of mine in Poland on what turned out to be a 400Mb connection after I suggested he run up a speedtest.
Measuring the speed of your connection is something akin to wanting to know what the amperage rating of the power cable coming into your house. We don’t know because it’s enough for a house and unless we are planning to build a factory there, we don’t and shouldn’t care about it.
Unfortunately to test your speed isn’t quite as simple as spinning up https://speedtest.net, connecting to whatever server it reckons is your closest and hitting GO. It will give you a measure, but is it useful? Will it tell you how fast you can download a file or whether it is enough to watch 4K Netflix? Unfortunately, it probably won’t.
To understand why, we need to delve a little into the way data is moved across the internet and in particular over the most widely used protocol called “TCP”. Moving data around is not like sending water down a pipe, it is more akin to sending water down a trench. With water if you put too much water at the beginning of your trench, it will overflow and will not make it to the other end. Assuming we have plenty of water available, we probably won’t care about this as long as enough water makes it. One bit of water is the same as the next bit.
However data is quite different, it all has to eventually get there – you don’t want holes in your downloaded file. So anything that overflows has to be detected and resent by the sender. This re-sending process is a waste of capacity and effectively reduces the overall speed of downloading, so should be minimised. So the TCP algorithm incorporates in it a system for pacing it’s sending rate until it just starts to see lost data as an indication that it is going too fast and is overrunning part of the link. It called an congestion avoidance algorithm. It gets this information from the receiver who is constantly sending back information about what packets it has received and therefore what is missing. The key thing to understand is that any lost data creates a signal (via the receiver) to the sender to slow down its sending rate.
On a perfect data transmission channel no data will get lost until it exceeds the data rate of the channel, at which point data packets will be lost and the sender will peg back its sending rate to match the capacity of the channel. Given that most transmissions are over multiple channels with different data rates, the system quite correctly slows itself to match the speed of the slowest (least capacity) segment.
However what happens if part of the link isn’t working perfectly well and starts losing occasional random packets? The algorithm will mistakenly believe it needs to slow down to try an avoid this packet loss. You run up a speed test and your speed is much slower than it should be. What is the most likely cause of this packet loss? Your wifi! Wifi is a radio system, it is subject to interference and particularly in apartment building, congestion – too many people trying to use the available radio capacity at once. 2.4GHz wifi has just 3 channels, 5GHz has many more, around 30, but because of the higher frequency will not go so far. Once the signal gets too faint you have more packet loss.
Unfortunately this effect of random low level packet loss is not constant. Because of a side effect of the way the TCP algorithm works, latency, the time between a bit of data being sent and the signal back from the receiver, has a massive effect. A lower latency (closer) sender can cope with much higher packet loss than a higher latency one. This is due to delays in the sender algorithm getting updates on what is going on, it tends to overshoot or undershoot the correct sending rate more often.
The net result is that if you run a speedtest to a server just 5ms away over your dodgy wifi you will still get a high speed reading. Try the same test to one 30ms away and your reading is much lower. So which is correct? The answer depends on what you are using your connection for. If you are in Perth and most of your traffic comes from Sydney (because in Australia almost everything is hosted in Sydney), then getting a speedtest reading to a server in Perth isn’t very useful, because that is the not speed that you will be seeing in real life.
At Launtel we have recently taken on services via Vocus. The downside of this arrangement is that, at least in the short term, all the traffic is “backhauled” to Sydney before being handed to us. So the closest place we can put a speedtest server to you is in Sydney. Given that most people’s traffic is going to go to Sydney anyway, this is not an issue, but it will affect the speedtest results when comparing to another RSP who has a speedtest server much closer to you. However I would argue this isn’t real. What is worse is sometimes people test against a local server from our network and then the traffic has to make the trip to Sydney and then back to the local server, increasing the latency even more.
However at this point I need to remind you that it is not the latency that is the problem, it is the low level packet loss plus the latency that causes this discrepancy in speed between a local test server versus a remote one. So if you are seeing this, the first step has to be to remove the most likely cause: your wifi. Run the test using a cabled in PC (sorry mac people, I know you guys can’t stand cables, but you will have to get an ethernet adapter!). If that is still showing a difference then there is an issue in your NBN connection or our network. Remember if you seeing a fast reading from a local speedtest server, it is likely it masking your problem. Unless you can understand the result you should always run a speedtest to Sydney on any RSPs network, because that is probably the one you care about.
In the meantime we will continue to roll out our network and put speedtest servers close to people, even though it is technically pointless, just because it is good for marketing and avoids me having to explain the above. 🙂
March 9, 2020