Use Apple’s networkQuality Tool to Test Internet Responsiveness
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.
I recently stumbled across an article in MacRumors describing a new (in Monterey) Apple utility for measuring network speeds. Here are results from a few quick tests that may be of interest.
My test environment:
Ookla Speedtest measures around 620/510 Mbps.
Apple’s networkQuality utility (located at /usr/bin) gave much slower results.
An example:
I ran it a few times and got varying results: 91/201, 100/275, 102/350, 98/394.
The download speed is pretty consistent, and always measures less than the upload.
Sometimes much less.
Little Snitch reveals that the host name Apple is using to do the speedtests is aaplimg.com, and that the servers used are part of clusters in NYC and Newark with IP addresses like: 17.253.15.47, 17.253.15.3, 17.253.14.27, 17.253.97.37.
No doubt the aaplimg.com hostname will resolve to different IPs depending on the location of the host doing the lookup.
The Ookla Speedtest program uses test servers that are ‘closer’ to my location (in Canada) than the NYC/NJ servers used by the networkQuality utility. I believe that Ookla uses ping tests to determine appropriate (nearby) server choices.
@ace will be pleased to know that if I select a test server at Cornell, Ookla measures 592/505 with ping time of 18msec. The Cornell campus has an excellent connection to the internet backbone, and thence to (at least) eastern Canada.
It’s not clear if the slower results obtained by the macOS utility are due to limitations in the networkQuality program, in the various Apple test servers, or bottlenecks in the internet connection from here to there. Probably some of each.
Most of the time, I don’t need a whole lot of details. I need a rough idea and usually more about downstream than up. That’s what fast.com is good at in spite of its various limitations.
Just a note that I moved the two previous posts into the article’s comments because they appeared literally minutes before I posted the article.
I know it’s not specifically speed related but gee I miss the Network Utility app. I just don’t understand why Apple would remove such a useful utility which I used every week around the office.
Apple’s mantra for many many years:
“Knowing what to leave out.”
Apple user experience for many many years:
“Where did ______ go? I use that all the time.”
sigh
@trilo
ditto
I kept a copy of Network Utility from Mojave and it continues to run just fine in Big Sur. Be advised, however, to keep a copy outside of the Applications folder since Apple re-deprecates it each time it does a system or security update
It was pointed out by another TidBITS Talk-er you can run ping, at least, in Terminal, too
I first became aware of this handy little executable back in early November on Dan Petrov’s blog (Blog | DanPetrov). A little later, I saw an app on the Apple Store titled "Network Quality Test. As far as I can tell, the author of that app charges 99¢ to open Terminal and type networkQuality.
And BTW, if you want your actual ping speed, just keep Terminal open and type ping followed by a space and the IP of your computer. Use Control C to stop and get a summary.
I did not know that Network Utility was gone because I never use it. I see that if you try to start it, you get this message: “For networking tools netstat, ping, dig, traceroute, whois, finger, open terminal and type the underlying command at the command line.” I think Apple did the right thing here. The Network Utility was a redundant frontend to the UNIX tools. Instructions for how to use them is one web search away.
For my videoconferencing I had concluded that using ethernet worked quite nice, wifi not so. The networkQuality tool confirms it.
WiFi
Upload capacity: 63.310 Mbps
Download capacity: 82.433 Mbps
Upload flows: 20
Download flows: 12
Responsiveness: Medium (249 RPM)
Ethernet
Upload capacity: 167.930 Mbps
Download capacity: 338.662 Mbps
Upload flows: 20
Download flows: 12
Responsiveness: High (1474 RPM)
The aaplimg.com server is in Copenhagen. Our Scandinavian sister country across the sea. Servers in Norway, Sweden or Finland would probably give better RPM.
In Terminal:
ping Norwegian newspaper website.
I’m intrigued that you saw such a difference between Ethernet and Wi-Fi. I tested that here too, but got exactly the same results with both, which suggested that my problems were at the router and not related to the LAN. I wonder if that implies that your Wi-Fi gateway has some issue that’s bypassed when you connect via Ethernet?
Yes, this is a limitation of my old Wi-Fi system I am well aware of. I have ethernet hubs in all rooms where we use computers. Via ethernet, my provider’s speed is the limiting factor. Wi-Fi is for surfing and light work. The reason I stick with my old Airport Extremes is that the Wi-Fi is very stable.
So how old is your Extreme? Mine is the final generation and I regularly see it push 600 Mbps across wifi. Granted, that’s not enough to exploit the 1 Gbps fiber we have, but close enough for my home purposes. AT&T recently came into our neighborhood offering 1/3 the bandwidth of our existing fiber plan at a colossal $3 savings. LOL. At least at 300 Mbps my APExtreme would no longer be the limiting factor.
I think I’ll stick with our small local provider. I’ll consider the $3 a service charge for not having to deal with AT&T. 
It is from 2011. Speed test to a Norwegian server via Extreme gives 500Mbps down and 350 up which is what I pay for.
The issue is that Network Utility was available on every Mac. When I was managing 40 or 50 machines at work, it was the first place to start when someone had a network, printing, web access issues. It’s hard to Google search instructions when their network is broken. It’s just another example of Apple deprecating a perfectly useful utility.
Why not just leave it there? it’s not like it would be costing them vast resource dollars.
From the article: The likely reason that upload speed dropped when switching to Smart Queue Management is that it’s going to reserve some bandwidth for TCP ACKs and other replies - which improves the overall responsiveness of the connection, but at the expense of max single upload speed.
(I can’t guarantee that’s what it’s doing of course - but that’s a common networking trick if you’re manually setting up firewalls/etc.)
Thanks for the intro. Here’s mine just now:
networkQuality
==== SUMMARY ====
Upload capacity: 495.098 Mbps
Download capacity: 280.100 Mbps
Upload flows: 20
Download flows: 12
Responsiveness: High (4705 RPM)
I did the same sequence and got much lower results from the NetworkQuality process.
For instance, OOKLA said download 138 and upload 184 for our town operated ISP.
However, Network quality says download 126 and upload 34.
I’m having trouble understanding this huge difference in the upload numbers.
Yes, @dstaal, I think you’re basically right.
There used to be a standalone device called the Broadband Blaster, IIRC. It went in between your modem (DSL or Cable) and your router. Ethernet in, ethernet out, and power. That was all it had.
How could putting a device right there make a difference in your connection speed? It didn’t speed up your connection. It worked by making sure that your modem upload buffer was never full. If your upload buffer is full, anything you try to send out gets put in line behind a megabyte or more (however big your modem buffer is) of traffic.
If you’re browsing the web, each time you try to load a page there will be dozens of requests for page content that you send out into that buffer. So you have to wait for those requests to actually get out before you can ever start receiving the HTML, image, javascript and CSS files you need to render the page.
Cable modems are (or were) particularly bad at having large buffers that slowed down your round trip requests. This is why turning on Quality of Service always slows down your max upload speed. You don’t want any buffers getting full. And the only way to do that is to go slightly slower than your modem can handle for uploading so its buffer is always empty or almost empty. (The buffer only fills up when the modem has more stuff to upload than the connection can handle.) If you keep the buffer empty, then, the instant you try to send out a request, it will get out. Or the instant you try to send out another video frame, it will go out. And then, of course, you’ll get responses quicker, and the number of round trips you can get in a minute will go way up.
All of this just by slowing your uploads a little bit.
@Joseph There’s one additional thing which that can do, which I mentioned but takes a bit of lower-level understanding of the protocols: When you’re downloading something from anywhere using TCP, after every packet of data, your computer sends a small message back saying ‘I’ve got it’. If the other end doesn’t see that message within a certain amount of time, it assumes the packet didn’t get through, and sends it again.
But the routers in the middle usually just treat that reply as any other message, and if your upload is full are as likely to drop/delay it as any other packet you’re sending out. And if they do, you get the same download data multiple times, until one of your replies gets through.
However, if you reserve a bit of upload bandwidth and dedicate it to just those packets, then your downloads get through smoother and faster, with less stuttering. Add that to the issue you mention of not filling overly large buffers, and you’ve effectively made both directions more responsive, by just dedicating a bit of upload bandwidth.
Interesting. I didn’t realize that.
The difficulty of doing QOS well is that you need to know how much upload bandwidth is available right now. With network congestion, and typical ISP performance, the number can go up and down. That means the easiest way to improve QOS is to hold back a significant percent of the available upload bandwidth, just in case in an hour your bandwidth is lower.
Adam,
Your comment that you saw the same results with WiFi and Ethernet caught my eye. Out of curiosity, I did a few more tests.
With M1-MacBook Air hardwired to GigE switch and thence to the internet through a GigE-capable router and a 500/500 optical fibre:
Using WiFi, connected to a Ubiquity Unifi AP-AC-Lite (802.11ac, 5GHz, 10’ away):
Using WiFi, in another part of my house, connected to a TP-Link C2300 (802.11ac, 5GHz, 10’ away). The TP-Link is configured as an AP, not doing any routing.
Most surprising is that the d/l speed over the Unifi AP is faster than over wired (143 vs 98). That’s not consistent with my UX - I’ll often plug in the MBA prior to doing a big download since it consistently seems faster that way.
OTOH, the drop in RPM over WiFi is quite significant.
And it’s interesting to see that the TP-Link is quite a bit slower for download than the Unifi AP (88 vs 143). During the tests, the TP-Link had no other traffic.
I wouldn’t say that’s the easiest - easiest is to ignore that and just assume you only have control over your own network and the gateway, then take a snapshot view of the upload and work with that.
Yours is often a better course of action obviously.
Best would be to work directly with each step to work out all the issues along the way - which can be done in some limited scenarios, but typically isn’t realistically possible.
So the difference between our setups, I think, is that your Ethernet connection goes to your router through a GigE switch, bypassing your Wi-Fi access point entirely, whereas in my test, my Ethernet connection still goes through my Eero base station.
I’d run the tests a few times on each to get a better sample. The lower ethernet speed is likely caused by a fluke at the time of testing, some background DL you didn’t know about or something like that.
If it’s consistently slower via ethernet, then I’d suggest you take a look at this article which talks in part about ethernet via USB-C on an M1 computer:
That’s a bit of an oversimplification. If it requied every packet to be acknowledged, things would slow to a crawl.
Instead, TCP implements a sliding window, where each end maintains a fairly large buffer for incoming and outgoing data. Acknowledgement packets are periodically sent representing a range of data (e.g. “I’ve received everything up to byte 12345”).
But you are right that if ack packets get dropped or delayed too much, it will slow down the session quite a bit.
Internet core and edge routers (e.g. those run by service providers) aren’t as dumb as you might think. There are rather elaborate systems of prioritizations set up in order to maximize end-to-end throughput. (This, BTW, is one of the reasons service providers object to network neutrality laws - some such proposed laws wouldn’t allow this (or any other) kind prioritization, which would definitely hurt everybody’s experience.)
The other problem is that you can probably only control bandwidth on your own router. You may have no ability whatsoever to affect your ISP’s edge router and almost certainly none whatsoever about any routers further away.
There is the RSVP protocol, designed to allow applications to request end-to-end resource reservations for network-wide QoS. It can, for example try to guarantee a 64Kbps link for a VoIP session or prioritize your gaming traffic above bulk downloads. But protocols like this work best when all the routers along the path participate in the reservation process, and you can be certain that not all will. Internet core routers definitely won’t, and your ISP’s routers probably won’t. But the protocol is designed to deal with this - the requests will propagate end-to-end and those routers that support it will reserve resources while the rest will not.
Joseph,
Agree 100%. Today’s d/l result over ethernet is quite a bit slower than what I saw a few days ago. I’m going to re-run the tests again when the other resident is off-line/sleeping/out shopping…
Thanks so much for posting the link to the overengineer.dev article. Fascinating reading.
I’ve not seen any evidence that my ethernet link is downgrading to 100baseT. The GigE switch is on my desk next to the MBAir, and the speed LED will show orange if/when a device syncs at 100. I’ll keep an eye on it. However, the interface chip in my cheap no-name USB-C hub is a Realtek 8156, not the much-maligned 8153 that’s cited in the article. Perhaps I got lucky when I chose the hub on Amazon.
Correct. My router is in the basement, adjacent to the telco’s fibre modem. The WiFi coverage from the router’s WiFi is pretty poor, so I’ve sprinkled a few APs around the house to mitigate.
Here is another service that I use quite often. https://speed.cloudflare.com/
Ah now that brings back memories. I used to work at one of Australia’s larger universities and we discovered bolo back when it was a thing. The Friday afternoon battles were epic! It sort of still runs (on LANs) but the screen scrolling doesn’t work good enough to enjoy it.
Connecting from Spain, I’m sure aaplimg.com servers will be faster that mensura.cdn-apple.com
Can anybody provide the command equivalent to:
networkQuality -C https://mensura.cdn-apple.com/api/v1/gm/config
The connections with this default server is very slow. That’s why I would like to test a different server.
Hey folks, this article helped me a lot, but unless I’m missing something, it doesn’t address the idea of latency delay if our local gadget is using VPN. For me, when experimenting, I got very different results when I had my private VPN provider service active vs. inactive. Just food for thought; it’s one of many variables in this dialogue.
Mike
Can you share your results? I don’t use a VPN, so I have no sense of what would happen, or what variables you could tweak to change things.
Sure, results below, all with my Ethernet cable disconnected. Wifi setup: all hardware is < 2 years old as of 2022_08. Meaning my Mac (M1), MacOS (Monterey 12.5), gateway_router (tp-link WiFi 6, configured for WPA-3 security), and Netgear cable modem (DOCSIS 3.1). Purchased download capacity from my ISP is about 300 Mbps.
My summary for latency results, organized by whether my 3rd-party VPN is off vs. on, and showing output from SpeedTest vs. networkQuality from Terminal:
VPN off - Speedtest ping = 11 ms; terminal RPM = 560 (medium)
VPN on - Speedtest ping = 13 ms; terminal RPM = 60 (low)
That’s quite a spread indeed. Do the raw download and upload rates also differ much too, or is it just the latency?
Yeah, generally also a wide spread, but less consistent across the use cases:
VPN off:
Speedtest download 343 Mbps; upload 20 Mbps
Terminal download 256 Mbps; upload 30 Mbps
VPN on:
Speedtest download 240 Mbps; upload 12 Mbps
Terminal download 276 Mbps; upload 21 Mbps
As FYI, I chose a local server in Speedtest, but left networkQuality as its default.
Not terribly surprising given that a local Speedtest server to you is unlikely to be local to the VPN server you used.
Hi Adam, I noticed that Nick Pappas posted a question a while back, that happens to be similar to mine, and no one seemed to respond, so I will ask mine: I have a 250mbps fibre connection via Hyperoptic and an Orbi wifi6 router with 1 satellite; with my 2021 M1 MB Pro on the 5Gb wifi connection using the MacOS Ookla SpeedTest I get down- and upload speeds in the 250-260 mbps range (as I do with the SpeedTest on my iPhone and iPad); when I use the Terminal > networkQuality command my download speeds are mostly similar but my upload speeds are approx 20 (!) mbps. After reading yours and other articles about networkQuality I was (and am) still scratching my head.
I called Apple Support and talked with a Sr Advisor about this seeming discrepancy. Thankfully he didn’t suggest wiping and restoring from backup. What he did say surprised me - basically, at least in Europe as I understand it, Apple Sr Support Advisors don’t use Terminal nor the networkQuality test; they do use Ookla SpeedTest and take that result to be ‘true and accurate’. And he said he didn’t think there was anything wrong with my machine.
My questions, and perhaps Nick’s from a while back, is what or perhaps where in the machine is networkQuality measuring relative to what/where SpeedTest is measuring? Are they measuring different ‘circuits’ or something like that? If the two tests are measuring the same phenomena except for the parallel/serial aspect, why hasn’t Apple found a way in these v expensive machines to manage upload speeds more effectively? Thank you.
It’s a good question, and I don’t know the answer. Have you tested an actual upload of a large file to a remote server to see what throughput you get? That would be the litmus test.
Thank you, Adam. No, I haven’t - what stimulated me and led me to discover networkQ was wondering whether zoom problems like lost audio frozen video were on my end or the other person’s end. I still don’t know how to figure that out! And I have this extra (spd test variants) ‘problem’ to worry about!
Re uploading a file - do you mean like to dropbox or … even iCloud? How big a file would I need and how would I measure the speed in real time? Activity Monitor?
Are your issues isolated to Zoom, or more general (e.g., YouTube or Netflix videos playing at lower quality, FaceTime calls interrupted, interruptions in other audio streams)? You certainly have plenty of bandwidth for any of these activities.
When the Terminal command networkQuality is run without parameters, the uploaded and download testing occurs in parallel (i.e. at the same time). With traditional speed tests (like Ookla), the upload and download tests are sequenced (i.e., first, the download and then the upload.) If you want to simulate that testing, use the command:
For example, using the Speedtest app to my ISP, the result I see is 941 Mbps download, 940 Mbps upload. Using networkQuality with no parameters, the result is about 350 Mbps upload, 863 Mbps download. Using networkQuality -s, the result is 877 Mbps upload and 889 Mbps download.
To see the documentation for networkQuality, use the command networkQuality -h.
This link pointed me to the explanation.
I haven’t tried fooling around with quality of service (QoS) parameters on my router, but prioritizing uploads should probably affect the result of the vanilla command.
Thank you Jeff; yes, it was really only zoom. But having discovered the difference I’m now more curious about what causes that and whether it is only the serial/parallel testing attribute.
Thank you Alan. I will try -s.
I see that your upload speeds with networkQuality and no parameters, ie parallel, drop to about at third the speed of serial. Mine with no parameters drop by an order of magnitude (from ~240 Mbps to ~20 Mbps). That seems a huge degradation to me, and puzzling. I will try the ‘ -s’ and the ‘ -h’ though.
My internal network maxes out at 1Gbps, but my connection to my ISP (Sonic.com) is supposedly 10Gbps (using a direct connection to my MacStudio, I’ve gotten a Speedtest measurement of about 8.1 Gbps down/ 7.1 Gbps up). So, I do have extra capacity on my Internet pipe.
Just a heads up, if like me you copy and paste Alan’s terminal command it won’t work because there’s a typo. It should be
networkQuality -s
Update: if I use
networkQuality -safter a few passes of 0.0 uplink capacity, the uplink and downlink are much more similar (216, 265 Mbps, respectively) than in the parallel mode.So for whatever reason, is the takeaway that the M1 chip as configured in the MB Pro has a hard time with parallel streams and pays more attention to the downloads?
It feels to me more like a network issue than a processor issue, but that’s just a gut feeling.