You can see the BITAG report, ‘Latency Explained’ and read more about how working latency is related to bufferbloat, but in short, working latency measures how badly other Internet traffic can affect your video conference or gaming session. Let me explain.
Most computer networks are idle most of the time. When you measure latency on an idle network, for instance by pinging Google, you typically get the best-case latency. This is a bit like using Google maps travel times outside of rush-hour traffic and assuming that is how traffic conditions are at all times of the day.
What about travel times during rush-hour traffic? That’s where the problems are likely to be anyway, right? Tests for working latency create traffic to ensure the network is working on something, and then measure latency. This produces more realistic results because we often travel during rush hour (it’s rush hour for a reason!). In fact, your own everyday Internet use, like loading a website or sending an email, can trigger a short-lived rush-hour event. Many home routers allow ‘greedy’ applications (like Internet browsing, downloads, and video streaming) to cause delays for latency-sensitive traffic (video conference, gaming). Working latency measures how bad this can get.
Ideally, the working latency should be as close to the idle latency as possible. If the difference between the two is more than 30ms, it is likely to cause problems. The good news is that the issue can be fixed, even if your ISP does not cooperate. If your network has this ailment, here are a few things you can do:
- Try calling your ISP and ask why their working latency is bad
- Upgrade your home router and Wi-Fi network
- Change some devices, like game consoles, to Ethernet instead of Wi-Fi
You can test your working latency right now, using this excellent tool directly from a browser.
ISPs can also use methods like Broadband Forums QED standard to monitor working latency in their networks.
Bjørn Ivar Teigen is Head of Research at Domos, and a PhD candidate at the University of Oslo. His research interests are in queuing theory, distributed systems, and Machine Learning with applications in modelling and optimizing real-world networks
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.