Where the bottleneck went

My internship has finished and my master's degree is due to be conferred at the end of October, so for once I have some free time. I've spent it sorting out the flat, and the home network was next on the list.

I pay for a 3G fibre plan, and every device in the flat was topping out around 940 Mbps.

When the line was installed, the technician plugged a laptop straight into the ONT and measured 2190 Mbps down and 2166 up. Incoming optical power was −16.35 dBm, well within spec. So the fibre was fine, and the problem was somewhere inside the flat.

A chain of network hardware runs at the speed of its slowest link. Fixing that link doesn't make the whole chain fast. It just makes the next-slowest link the new limit. That happened at every step below, so most of this note is about finding where the bottleneck went after each change.

Stage 1: a gigabit port on a multi-gigabit line

The old router was a TP-Link Archer AX72. It's a decent Wi-Fi 6 router, but its WAN port and all four LAN ports are 1GbE. After Ethernet framing and TCP/IP overhead, gigabit Ethernet carries about 940 Mbps of real traffic. That was the ceiling for the whole flat, whatever the fibre could do.

The fix had been in a cupboard for a year. An ASUS RT-BE58U came free with the 3G contract I signed last year, and I never set it up. It has a 2.5GbE WAN port, which tops out around 2.35 Gbps, already more than the 2.2G the line delivers.

After the swap, no single device gets anywhere near the WAN limit. So a faster fibre plan with this router would not make anything faster.

The RT-BE58U is Wi-Fi 7 but only dual-band (BE3600): up to 2882 Mbps on 5 GHz, 688 on 2.4 GHz, and no 6 GHz radio. It has one 2.5GbE port that doubles as the WAN, three gigabit LAN ports and a USB 3.2 Gen 1 port. One thing to watch: if the wall cable goes into any port other than the 2.5G one, the whole flat drops back to 940.

Setup took a few minutes:

• WAN by DHCP. M1 doesn't use PPPoE.
• 2.4 and 5 GHz under one SSID (Smart Connect), reusing the old router's name and password, so every device reconnected on its own.
• WPA2/WPA3 transition mode.
• On 5 GHz the router picked channel 40 at 160 MHz by itself. That block covers channels 36 to 64, and the upper half (52 to 64) is DFS.
• The ASUS advertises country code US, which matches the region printed on its back: it's a US unit. (The AX72 advertises SG.) The channels used in this note are allowed under both US and Singapore rules, so it hasn't mattered here.
• The WAN light on the front stayed red even though speed tests were fine. On ASUS routers that light shows the result of the router's own connectivity check (periodic pings and DNS lookups). It doesn't mean the connection is down.

Stage 2: the radio in the client

With the WAN port out of the way, the limit moved to the devices. A Wi-Fi link's raw PHY rate comes from the number of spatial streams, the channel width and the modulation. Every device here has two streams (2×2):

In practice, TCP throughput is usually 60–70% of the PHY rate. Here's the living room, in the same room as the router, measured in two separate rounds:

1479 Mbps on a 2402 Mbps link is 62%, right in the expected range. The same phone in the same room read 1291 in the first round and 1479 in the second, a 15% difference with nothing changed. A single speed test is that noisy, so I don't read much into differences smaller than that.

The Wi-Fi 7 iPhone 17 Pro was no faster than the Wi-Fi 6E iPhone 15 Pro; in the second round the 15 Pro came out ahead. On this router that's what you'd expect. According to its FCC filing, Apple's N1 chip supports 160 MHz channels, not the 320 MHz that Wi-Fi 7 allows, and 320 MHz only exists on 6 GHz, which this router doesn't have. It's also unconfirmed whether N1 uses 4K-QAM on the iPhone; one test found it switched off on an M5 Mac. So in practice both phones got the same link: 160 MHz, 2×2, 1024-QAM, and the Wi-Fi generation made no difference to throughput.

Where Wi-Fi 7 might still help is latency under load, through features like Multi-Link Operation, preamble puncturing and Multi-RU. The second round recorded latency for each device:

Idle latency is the same for both phones, but under load the 17 Pro stayed at 22 ms while the 15 Pro rose to 46. That fits the idea. It's one run per phone, though, taken a few minutes apart rather than side by side, so I'd want several runs before believing it. (An earlier round showed the 17 Pro's loaded latency dropping from 28–52 ms on the old router to 18–42 ms on the new one, but that compares two routers, so it says nothing about the phone.)

The MacBook is still the odd one out. In the first round its link rate showed 1200 Mbps, close to the 80 MHz 2×2 maximum, yet it downloaded only 419 Mbps, less than its 525 Mbps upload. macOS's built-in networkQuality reported 242 down, 138 up and 13 ms idle latency. (networkQuality tests against Apple's servers and usually reads lower than speedtest.net.) The second round was better, 542 down and 554 up, but still far below the 775 the same Mac later managed in a bedroom through the other access point. So the Mac itself can go faster. I don't know what holds it back in the living room.

Stage 3: strong signal, slow link

The new router barely helped the bedrooms. The iPhone 15 Pro went from 620 to 674 Mbps in the second bedroom, and only got a little over 200 in the master bedroom.

I assumed distance at first. The MacBook's Wi-Fi diagnostics (hold Option and click the Wi-Fi icon) didn't support that:

The signal was strong and well above the noise floor, yet the link only negotiated a mid-range modulation. That pattern usually means interference from other networks on the same channel, or collisions and retransmissions, rather than distance. It also explains why moving the antennas didn't help.

macOS's own scan (Wireless Diagnostics) showed how crowded the area is: 87 networks in range, 19 on 2.4 GHz and 68 on 5 GHz, six of them on channel 40 like mine. It suggested channels 136 and 165 instead. It also showed zero networks on 6 GHz; I come back to that number near the end.

I didn't use either suggested channel. Channel 165 is at the edge of the UNII-3 band and can only run at 20 MHz, a quarter of the width. Channel 136 is in UNII-2e and is a DFS channel. Before using it, the router has to listen for radar for about 60 seconds, and if radar shows up it has to leave the channel, which briefly drops Wi-Fi. macOS picks its suggestions based only on how busy a channel is, not on how wide it can run or whether it needs radar checks.

The main router could have moved to 149, away from the networks on 36 and 40, but the block at 149 only goes up to 80 MHz, which would probably cut the living-room phones from about 1.4 Gbps to 700–800 Mbps. I didn't want to trade the living room for the bedrooms, so I left the router alone and planned a second access point near the bedrooms on channel 149. I assumed 149 was quieter. I hadn't checked, and it turned out not to be.

The cable problem

The flat's wiring runs to a patch panel in the storage room with three data ports, D1 to D3, all CAT6. D1 goes to the living room and already carries the internet from the ONT to the router's WAN port. D2 and D3 go to the bedroom walls, but they aren't connected at the panel end. Because the router is in the living room, there's no second cable back to the panel to feed them.

There is technically a fifth option: send both the internet and the home network over D1 as tagged VLANs, with a small managed switch at each end to split them. It works, but it needs two managed 2.5GbE switches plus VLAN setup, and the internet and bedroom traffic would then share one cable, which creates another shared limit. Option D was simpler and avoided that.

Adding the AX72 as an access point

The plan for the old AX72, at the bedroom end of the flat cable:

• Reset it and switch it to Access Point mode in TP-Link's Tether app, so the ASUS keeps handling DHCP and the AX72 only bridges.
• Give it the same SSID, password and security mode as the main router. The security mode matters: if the two differ, iOS treats them as separate networks and drops the connection when moving between them.
• Fix its 5 GHz radio to channel 149, away from the ASUS's 36–64 block.

Tether showed all three as done. Two of them weren't, and I didn't find out until later.

Even set up properly, this is not a mesh:

• The two units don't coordinate. Each device decides for itself when to switch, and iPhones and Macs tend to stay on the current access point until the signal gets poor.
• There's no 802.11k/v/r roaming assistance, no central management and no config sync.
• To help, I set ASUS's Roaming Assistant to around −70 dBm so it nudges weak clients off the main router, and turned down the AX72's transmit power so it mostly covers the bedrooms.

It still gives the main thing people buy a mesh for, a strong signal near the bedrooms. And the link between the two units is a cable, which is steadier than the wireless backhaul most mesh kits use.

First results

The second bedroom sits between the living room and the master bedroom. The master bedroom improved about threefold.

I wanted to know what was limiting the second bedroom at 918, so I ran the iPhone 15 Pro and the MacBook there at the same time. The iPhone got 639 and the Mac 319, a total of 958. Two devices splitting roughly 940 between them pointed at something they shared, but I couldn't say whether that was the gigabit cable or the airtime on the access point's channel. It turned out I didn't know what channel the access point was on.

What the access point was actually doing

To draw the channel chart for this note, I scanned again from the second bedroom with the MacBook. The Mac was connected on channel 40 at 160 MHz, at −30 dBm, with country code SG. The AX72 was supposed to be on 149, and my ASUS advertises US. Something very close to the Mac was sitting on the main router's channel.

The Mac's network settings explained it:

Two routers in a row. The AX72 was still in router mode, running its own DHCP and NAT behind the ASUS. Its web console showed 5 GHz set to Auto channel and Auto width, currently 40 at 160 MHz, on top of the ASUS's block. Tether had shown Access Point mode and channel 149 the whole time. Neither had actually applied. My best guess is that the mode change was lost when the AX72 rebooted and the phone running Tether lost its connection to it, but I can't confirm that.

So every bedroom number in the table above was measured through a second router, on the main router's channel, at 160 MHz. Devices on the AX72 were on a separate network, which is why the ASUS app showed the MacBook as offline. It also means Bonjour discovery couldn't cross between the two halves of the flat, so something like AirPlay from a bedroom to the living-room TV wouldn't have worked.

I made both changes in the AX72's web console this time, then checked them from the Mac rather than the app. The traceroute's first hop became the ASUS, the Mac got 192.168.50.65 from the ASUS, and its link moved to channel 149 at 80 MHz. I set the width to 80 MHz explicitly instead of Auto, so it can't drift back to 160.

The ASUS app turned out to be unreliable too. I'd understood that it lists the AX72's clients as "wired", since their traffic arrives over the cable. With everything fixed, the MacBook, confirmed on channel 149, still showed up as a 5 GHz client of the ASUS. Only the AX72 itself showed as wired. The reliable checks are the Mac's own channel (149 is the AX72, 40 is the ASUS) and the AX72's own client list, which showed the iPhone, iPad and MacBook on its 5 GHz radio.

Counting the neighbours properly

The first scan counted networks by their primary channel. That undercounts. The primary channel is only where a network sends its beacons and control frames; its channel width decides how many neighbouring 20 MHz channels it actually transmits on. For a network on channel 40:

That's also why "channel 40 at 160 MHz" involves DFS even though channel 40 itself doesn't.

I rescanned with the AX72 fixed, using CoreWLAN directly so I could count each network on every channel its width covers. My own access points are easy to tell apart by signal strength: the AX72 at −29 dBm and the ASUS at −41, while the loudest neighbour is around −65.

The "loud" counts jump around between scans, since many networks sit close to −82 dBm. The totals are steadier.

So 149 isn't quieter than 36–48. It's at least as crowded. The genuinely quiet part of the band is 116–144, which is exactly where macOS pointed with channel 136. Its logic was fine; it just doesn't weigh the cost of DFS.

149 is still the right place for the AX72, for two reasons I didn't have at the time. It needs no DFS. And it stays off the strongest interferer in the bedrooms, which is my own ASUS: at −41 dBm it's more than 20 dB louder than any neighbour, and it carries most of the flat's traffic. The AX72 on 36–48 at 80 MHz would also avoid DFS, but the two access points would then take turns on the same airtime, and the living room would slow down whenever the bedrooms were busy.

Measured again

The new numbers were taken around 6:30 pm, and I haven't ruled out evening traffic from the neighbours. Re-running the same tests late at night would separate that.

The two setups had different bottlenecks, and the numbers show which:

First setup. The iPhone 15 Pro was on a 160 MHz channel through the AX72 and got 925. On the ASUS's 160 MHz channel in the living room, the same phone got 1291 and 1479 in two rounds. Its radio had headroom, so something else stopped it at 925: the gigabit link between the AX72 and the ASUS. Two devices together hit the same ~940. This assumes the AX72 was already on 160 MHz during those tests. Auto channel selection normally picks once at boot and stays, but I can't prove it.

Fixed setup. At 80 MHz the iPhone's PHY rate is 1201 Mbps, and 833 is 69% of that, the top of the usual range. The radio is now the limit. Two devices together reach only 817, well under the cable's ~940, so the cable is no longer what limits them. The shared 80 MHz channel is.

Earlier I'd concluded that when two limits sit at the same level, no test can tell them apart unless you move one of them. Fixing the configuration moved one: halving the channel width dropped the radio's limit below the cable's, and after that the two were easy to tell apart.

The MacBook went from 420–600 to 775. It only ever uses 80 MHz, so it lost nothing from the narrower channel, and it gained from leaving the ASUS's channel and losing the extra router in the path. I don't know how much each of those contributed.

The overall trade: devices that can use 160 MHz lost some peak speed in the bedrooms, the MacBook got faster, every device is on one network, and the two access points no longer share airtime.

Wider channels, and DFS

Could the AX72 have 160 MHz back? Not without DFS. In Singapore every 160 MHz block includes DFS channels, and the block at 149 only goes to 80 MHz, since 160 would need channels 169 to 177, which aren't permitted here.

100–128 is the obvious candidate: almost empty, no overlap with the main router. The gain is modest, though. With a gigabit link behind it, the second bedroom tops out around 925 again; the master bedroom would gain more.

The cost is radar. Under the common FCC and ETSI rules, a router that detects radar on a DFS channel has to leave it and can't return for at least 30 minutes, and connected devices drop briefly while it moves. I'd rather not have that in the bedrooms without knowing how often it happens here.

The ASUS has been on DFS channels all along, since the upper half of its 160 MHz block is 52 to 64. So instead of guessing, I'm recording it. A background job on the Mac scans every 15 minutes and logs the ASUS's channel and width. A radar event forces at least 30 minutes off those channels, so it can't slip between two scans. The scan only shows that something changed, not why, since the ASUS can also change channel on its own; the router's system log covers the why. If a week goes by with the ASUS on 40 at 160 MHz throughout, the AX72 moves to 100–128. If not, it stays on 149. I'll add the result here.

What the next upgrade would and wouldn't buy

My contract renews next year. At the time of writing, M1's 10G plan costs less than the 3G plan I'm on, so the plan is to switch, add an ASUS RT-BE92U (tri-band BE9700, one 10GbE port and four 2.5GbE ports, 6 GHz with 320 MHz channels), move the RT-BE58U to the bedroom side as an AiMesh node, and retire the AX72. The ONT already has a 10G port, so it probably won't need replacing, though I still need to confirm that with M1.

Going by the same rule, here's what that would and wouldn't change:

• Single-device peaks won't go up. The limit is each device's radio, and a 10G plan only raises the WAN limit, which nothing is reaching.
• The limit for the whole flat goes up from 2.35 Gbps.
• A 2.5GbE link between the two units won't help the bedrooms as things stand. At 80 MHz they're limited by the air (817, below the cable's 940), not by the cable. It only starts to matter if the bedroom radio runs wider. The plan also replaces the bedroom radio at the same time, so it would be better to change one thing, measure, then change the other.
• A 6 GHz band. It has no DFS requirement, so wide channels come without radar checks. The iPhone 15 Pro, iPhone 17 Pro and iPad Pro support it, but the MacBook doesn't. 6 GHz doesn't get through walls well, so realistically it only helps in the same room as the router.

That brings me back to the 6 GHz result from the first scan. I had been reading "6 GHz: 0 networks" as proof the band is empty here. But the scan ran on the MacBook, and the MacBook has no 6 GHz radio. It could never have reported anything other than zero. The band may well be quiet, since fewer devices use it and its signals don't travel far through walls, but my zero doesn't show that. It's the same mistake I wrote about in the prompt caching note: a test that can only return one answer isn't measuring anything.

Options I looked at and ruled out:

Takeaway

Every change moved the bottleneck somewhere new: from the WAN port to the phones' radios, to a crowded channel, to the gigabit link behind the access point, and finally, once the access point was set up the way I thought it already was, to the airtime of a single 80 MHz channel.

Two habits did more than knowing which part to buy. One was finding the new bottleneck with a test that could actually give a different answer. The other was checking what the devices were doing instead of what their apps said. Tether showed Access Point mode on channel 149 for hours. A traceroute showed neither was true in under a second.