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:
The Ethernet issues were particularly annoying because the hub sometimes decided to downgrade its Gigabit connection to 100baseTX. I didn’t notice that too much while browsing, but backups to my NAS, in-home streaming of games, … those applications really suffered. It didn’t even tell you that, even if I forced it to 1000baseT in the macOS network preferences, it only ever negotiated 100baseTX. I was able to see that via my switches’ LEDs and its control panel, but there was no indication to the operating system.
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.
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.
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.
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:
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:
networkQuality -s
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.
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.
Yours is often a better course of action obviously.