从400 Mbps到1.7 Gbps:WiFi 7调试之旅
From 400 Mbps to 1.7 Gbps: A WiFi 7 Debugging Journey

原始链接: https://blog.tymscar.com/posts/wifi7speedhunt/

## UniFi Dream Router 7 WiFi 7 速度故障排除 为了支持即将到来的 2.5Gbps 网络连接和 WiFi 7,作者升级到 UniFi Dream Router 7,但最初体验到的速度远低于预期——大约 400-650Mbps,尽管使用的是支持 WiFi 7 的 iPhone 17 Pro Max。初步测试显示有线连接稳定在 2.3Gbps,表明问题出在 WiFi 上。 大量的调试发现问题并非 160MHz 频道宽度,而是 iPhone *实际上* 只以 80MHz 连接,尽管 SSID 配置了更高的宽度。在 UDR7 的设置中手动将 6GHz 频段宽度设置为 160MHz 并将发射功率设置为高,解决了这个问题。 关键经验包括使用 iperf3 的 `-R`(反向模式)和多流 (`-P 6`) 进行准确的 WiFi 测试的重要性,以及避免*针对*路由器本身进行测试,以防止 CPU 竞争。虽然 2x2 客户端由于开销和限制无法达到完整的 2.5Gbps,但作者现在能够稳定地达到 1.6-1.7Gbps,这符合 WiFi 7 的预期实际性能。

## WiFi 7 调试与网络性能讨论 这次黑客新闻的讨论围绕着一位用户调试 WiFi 7 的过程,最终达到 1.7 Gbps 的速度。对话迅速深入到优化 WiFi 性能的细微之处,特别是关于发射功率、信道选择和干扰。 主要收获包括:对在密集环境中最大化发射功率的担忧(一种“囚徒困境”),由于较少拥塞,在 6GHz 频率上使用更高功率的相对容易性,以及稳定连接比峰值速度测试更重要。用户们争论在速度可能导致延迟和不稳定时,优先考虑速度是否值得。 许多人强调当前基础设施和软件的局限性,指出即使拥有快速硬件,瓶颈也经常出现在 ISP、软件效率低下或大型游戏下载和数据密集型任务等现代应用程序的需求上。 几位评论者建议优先考虑可靠性,并选择较窄的信道宽度以获得更一致的体验。 最终,这场讨论强调了硬件、软件和环境因素之间复杂的关系,以实现最佳的 WiFi 性能。
相关文章

原文

I recently upgraded from a UniFi Dream Machine to a UniFi Dream Router 7 because I’m getting 2.5 Gbps internet in two weeks and figured I’d jump on the WiFi 7 bandwagon while I’m at it. My iPhone 17 Pro Max supports it, so why not? After setting everything up, I was getting nowhere near the speeds I expected. Time for some debugging.

The disappointing numbers#

My wired connection was pulling 950 Mbps through a 1 Gbps switch, and iperf3 directly to the UDR7’s 2.5 Gbps port showed around 2.3 Gbps. The backbone was solid. But on WiFi 7 (6 GHz, 160 MHz width), standing literally a foot from the router, I was getting around 400 Mbps with iperf3. With 10 concurrent streams it went up to 650 Mbps, but that’s still pathetic.

A quick note on my testing: I was using iperf3’s -R flag (reverse mode) which makes the server send data to the client instead of the other way around. This typically gives better results on WiFi since the AP has stronger transmit power than phones, and the phone only needs to send tiny ACKs back.

Meanwhile, reviewers were getting 1,635 Mbps average on 6 GHz with the UDR7, with peaks up to 1,890 Mbps. There’s even a YouTube video showing an iPhone 17 Pro Max hitting 1.9 Gb/s on 6 GHz 160 MHz. I was getting a third of that.

False start #1: “Maybe I’m testing wrong”#

I created a dedicated 6 GHz-only network with 160 MHz channel width on Auto transmit power. The spectrum was clean with no other 6 GHz broadcasts. I wondered if maybe 160 MHz was causing issues, so I tried switching to 80 MHz width to test that theory - but that made things worse at 374 Mbps total. So it wasn’t that 160 MHz was broken; something else was going on. Moving the iperf server from the UDR itself to my MacBook over Ethernet improved things to 727 Mbps, but still nowhere near the expected speeds.

At this point I knew the phone could only do 160 MHz width, not 320 MHz - that’s what Apple’s N1 chip is limited to. I hadn’t enabled IPS/IDS or QOS yet, though I was planning to since the UDR7 can handle it at full 2.5 Gbps.

Finding the first bottleneck#

After banging my head against this for hours, I had a hypothesis about my test setup. My wired MacBook could hit 2.3 Gbps to the router, so the network was fine. But looking at my iperf3 results when testing WiFi against 10.0.0.1 (the router itself), I wondered if that was the issue:

iperf3 -c 10.0.0.1 -P 6 -R -t 20 -w 2M
# ...
[SUM]   0.00-20.01  sec  1.30 GBytes   560 Mbits/sec    0             sender

Running iperf server on the router itself creates CPU contention between the WiFi scheduling and the iperf process. The router’s TCP stack isn’t tuned for this either. Classic mistake.

False start #2: “It’s a 2.5 GbE problem”#

Moved the iperf server to my MacBook connected through a USB-C 2.5 GbE adapter. Verified the port negotiated at 2.5G in UniFi’s port settings. Ran the test again:

iperf3 -c <mac_ip> -P 6 -R -t 20
# ...
[SUM]   0.00-20.01  sec  1.67 GBytes   718 Mbits/sec                  sender

Better, but still nowhere close to 1.9 Gbps. Time to check what UniFi was actually showing for the client connection during the test. That’s when I found the real problem.

The actual issue: 80 MHz, not 160 MHz#

Looking at the UniFi client details while running iperf, I saw this:

Ch. 37 (6 GHz, 80 MHz)
Tx/Rx Rate: 1.20 Gbps

Wait, what? My iPhone was connecting at 80 MHz channel width, not 160 MHz. Even though I had configured the SSID for 160 MHz, the actual radio was still on 80 MHz. The 1.20 Gbps PHY rate is exactly what you’d expect for 2×2 MIMO at 80 MHz. That explained the 650-900 Mbps TCP throughput perfectly. When I had manually tested 80 MHz earlier and got worse speeds (374 Mbps), it was probably due to testing against the router itself rather than the channel width.

The fix was in the UDR7’s radio settings, not the SSID settings. I went to:

  • Devices → UDR7 → Radios → 6 GHz
  • Set channel width explicitly to 160 MHz (not Auto)
  • Set transmit power to High

The working configuration#

After applying those changes and reconnecting:

iperf3 -c <mac_ip> -P 6 -R -t 20
# ...
[SUM]   0.00-20.01  sec  3.77 GBytes  1.62 Gbits/sec                  sender

Finally! The UniFi panel now showed:

  • 6 GHz, 160 MHz
  • Tx/Rx Rate: 2.4-2.9 Gbps

That’s exactly the expected PHY rate for 2×2 WiFi 7 at 160 MHz with 4096-QAM.

Why certain iperf flags matter#

During this journey I learned why specific iperf3 flags make such a huge difference:

The -R flag (reverse mode): As I mentioned earlier, this is crucial for WiFi testing. It’s faster because:

  • The AP has higher transmit power and better antennas
  • The phone only has to send tiny ACKs back
  • iOS’s TCP receive path is better optimized than its send path
  • Phones transmit at much lower power on 6 GHz

Multiple streams (-P 6): Overcomes single-flow TCP limitations like slow start, congestion window, and socket buffer limits. Four to eight streams usually hit peak; more gives diminishing returns.

TCP window size (-w 2M): Less critical on LAN where RTT is tiny, but can help with bursty traffic.

Why no 2×2 client hits 2.5 Gbps on WiFi#

Even with everything optimized, I’ll never see 2.5 Gbps on my phone. Here’s why:

The fastest PHY a 2×2 client can negotiate on 160 MHz WiFi 7 is about 2.88 Gbps (4096-QAM, MCS13). But that’s the raw link rate. After overhead:

  • MAC/PHY overhead (preambles, pilots, guard intervals, CSMA/CA backoff, block ACKs)
  • IP/TCP headers
  • Encryption overhead

Best-case TCP “goodput” is typically 60-75% of PHY on a clean single-client link. So 60-75% of 2.88 Gbps gives you roughly 1.7-2.1 Gbps. That’s why reviews land around 1.6-1.9 Gbps.

To exceed 2.0-2.1 Gbps you’d need:

  • 320 MHz channels (not supported on iPhones)
  • More spatial streams (3×3 or 4×4, but phones are 2×2)
  • WiFi 7 MLO using multiple bands simultaneously

Key takeaways#

For anyone else trying to maximize their WiFi 7 speeds:

  1. Don’t test against the router itself - Use a separate machine on >=2.5 GbE
  2. Check your actual channel width - The client details panel tells the truth, not the SSID settings
  3. Set transmit power to High for testing - But use Auto/Medium for daily use to avoid uplink/downlink imbalance
  4. Use reverse mode with multiple streams - iperf3 -c <server> -P 6 -R -t 20
  5. Stand 6-10 feet away - Too close can hurt signal quality

After all this debugging, I’m now consistently seeing 1.6-1.7 Gbps on WiFi 7 with my iPhone. Not quite the headline 1.9 Gbps some reviewers got, but definitely in the expected range for real-world performance. More importantly, I understand exactly why the numbers are what they are.

Now I just need my ISP to actually deliver that 2.5 Gbps upgrade&mldr;

联系我们 contact @ memedata.com