Videoconferencing has revealed to all of us how good—or poor—our Internet connections really are. However, if you’re just loading Web pages or reading email, it’s unlikely you can get a sense of throughput. Even watching streaming video isn’t necessarily a good test, since it stresses only downstream bandwidth and streaming services use lots of tricks to avoid jitter and buffering. But because videoconferencing requires decent bandwidth in both directions, plus relatively low latency to keep the audio and video streams synced, it provides a clearer picture of your network quality. If your video calls stutter or freeze, your Internet connection might be at fault. But how to quantify that? And if necessary, how can you fix it?
There are numerous tools for testing Internet connection speeds. Ookla’s Speedtest may be the best known, and you can also turn to Google’s tool—search for “speedtest”—or Netflix’s Fast. All of those should provide roughly similar results for download and upload throughput, but those two numbers don’t tell the whole story.
Latency, which is often overlooked, can play a key role when bandwidth is otherwise sufficient for your purposes. (Speedtest calls latency “ping.”) Latency measures how many milliseconds it takes for you to get a response from the remote server. Low latency numbers are essential for smooth video calls and responsive gaming, though it’s difficult to connect a particular latency measurement with perceived performance. Is a 100-millisecond latency good or bad?
Unfortunately, latency numbers reported by standard speed tests may not accurately reflect what you’ll see in the real world, such as when someone else on your network is enmeshed in a Zoom call, watching a 4K video stream, or backing up to an Internet backup service. High-bandwidth activities can cause latency spikes that spell trouble for otherwise good connections for everyone on the network. In other words, we need to think about latency when our networks are under load, not when they’re idle.
All that’s by way of introducing the networkQuality command-line tool that Apple introduced with macOS 12 Monterey. If you open Terminal and type
networkQuality, it will report on upload and download “capacity,” which is a better term than “speed” because Internet connections are essentially pipes—the larger the pipe, the more traffic it can carry, just like a larger pipe can carry more water. You’ll also see numbers for upload and download “flows,” which are reportedly the number of test packets used for the responsiveness tests. (I usually see 12 there, though I once saw 20 for upload flows and, another time, 16 for download flows.)
Most interesting is “responsiveness,” which measures the number of roundtrips per minute (RPM) under load and attempts to provide a number that better measures the effects of latency without using a time measurement. Along with being a nod to the “revolutions per minute” measurement from car dashboards, RPM is a “higher is better” metric that’s easier to understand. Its numbers tend to be in the three-to-four digit range, making them easy to compare. Plus, Apple interprets the numbers for you, offering Low, Medium, and High labels. Here’s how the company describes those evaluations:
- Low: If any device on the same network is, for example, downloading a film or backing up photos to iCloud, the connection in some apps or services may be unreliable, such as during FaceTime video calls or gaming.
- Medium: When multiple devices or apps are sharing the network, you may experience momentary pauses or freezes, such as during FaceTime audio or video calls.
- High: Regardless of the number of devices and apps sharing the network, apps and services should maintain a good connection.
Our old friend Stuart Cheshire, who explained latency 25 years ago in a two-part TidBITS series, “Bandwidth and Latency: It’s the Latency, Stupid” (24 February 1997), worked on the RPM metric at Apple and introduced it in a WWDC 2021 video. (Stuart also wrote the interactive networked tank game Bolo many years ago and was responsible for the Bonjour zero-configuration networking project at Apple. Few people know networking like Stuart.)
As a command-line tool, networkQuality has a variety of switches that could be useful—type
man networkQuality to see all of them. The tool’s options let you point at your own server instead of Apple’s and force the test to use a particular network interface (Ethernet instead of Wi-Fi, for instance), among other choices.
You might want to test responsiveness on your iPhone or iPad as well. Apple offers a WiFi Performance Diagnostics profile that those with Apple Developer accounts can install (see Apple’s support document for full instructions). Then go to Settings > Wi-Fi, tap the i button next to your network, and then tap Diagnostics and the Test link next to Responsiveness. (If you’ve already done one test, the Test link changes to the last result—tap that to run the test again.)
Apple’s latency measurement shows the company taking its own path once again, but, like Apple’s usual reasons for going its own way, the networkQuality responsiveness results better reflect your actual experience of latency. This new RPM metric isn’t proprietary—it’s an IETF draft with full details and even has open-source server code on GitHub. Wouldn’t it be great if these other tools took advantage of Apple’s work here to improve speed test results everywhere?
To be fair, if you click Show More Info after running a Fast test, it shows you latency results for both unloaded and loaded scenarios. As you can see below, my loaded latency is far worse (lower is better) than my unloaded latency, which corroborates my low RPM numbers from networkQuality.
What can you do about low responsiveness? More selfishly, what can I do about my terrible RPM numbers?!? I’ve been thinking that my 200+ Mbps downstream and 10+ Mbps upstream bandwidth was pretty good, and my raw latency numbers are always 30 milliseconds or below, which is great. But I’ve never found videoconferencing quality to be fabulous, though I’ve usually (and arrogantly, as it turns out) assumed that other people’s connections were at fault.
Apple’s networkQuality support page answers this very question, albeit somewhat generically.
If you’re using a Wi-Fi or wired network connection, some routers offer Smart Queue Management (SQM) to provide consistent high responsiveness, although these high-end home gateways generally require some expert manual configuration. The Apple Network Responsiveness test can be a useful tool for evaluating and comparing these home gateways, and it can be especially useful as a repeatable test when experimenting with different configuration settings and comparing the effects.
Some years ago, I replaced our Wi-Fi network’s increasingly flakey AirPort base stations with an Eero mesh system, and it has worked swimmingly. I can’t recall ever having to restart the primary Eero unit, something I had to do weekly with the AirPorts. (We’ve had connection glitches, but those are Spectrum’s fault and have nothing to do with the Eero system.) Some quick searching revealed that Eero has added a Smart Queue Management feature—called “Optimize for Conferencing and Gaming”—to its experimental Eero Labs settings. Since I’ve barely had to use the Eero app on my iPhone, I had to spelunk through every setting before I realized that Eero Labs has its own settings in the Discover tab. After that, it was trivial to enable Optimize for Conferencing and Gaming.
So did it work? Beforehand, my RPM numbers were always low, ranging between 89 and 144. After turning it on, they went stratospheric, ranging from 1315 to 1687! Fast’s loaded latency number also dropped by a factor of ten to 47 milliseconds. However, those are just numbers, and I won’t know for several weeks if it makes a noticeable difference in everyday video calls.
Alas, nothing is free in this world. When I was waiting for the iPhone screenshots above to upload to iCloud, I noticed it was taking longer than expected. That was unrelated, I think, but it caused me to look more closely at networkQuality’s numbers, where I discovered that my upload capacity had dropped by almost half, from roughly 10 Mbps to 5 Mbps. Tests through other tools also showed a reduction in upload bandwidth, though less extreme, generally dropping from 12–13 Mbps to 9–10 Mbps. I have no idea why enabling SQM would hamper uploads. In general, I’m willing to trade reduced upstream bandwidth for increased responsiveness, but it’s worth remembering that you can turn off SQM if you need raw upload performance.
Assuming, of course, that you can turn SQM on to start. As Apple notes, only some routers offer the feature, so you’ll have to research your particular router to see if it supports SQM and, if it does, how to turn it on. I recommend comparing network statistics before and after to see if it impacts your performance as it did mine. If you notice a real-world difference in videoconferencing quality, let us know in the comments.