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.
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.