Wild WiFi latency inconsistency

Installing and Using OpenWrt Network and Wireless Configuration
1

Problem

  • Ping from client to AP: 2-4ms, <1ms mdev.
  • Ping from client to an Internet host nearby: ~10ms, ~2ms mdev.
  • Ping from AP to client: 3-400ms.

Just... How? Why? What is going on?..

Hardware

  • APU2 board
  • Atheros QCA9880 radio, running as AC/WPA3
  • Client is using AX200, running Debian 12

dmesg log:

[    9.326647] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[    9.590676] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 0000:0000
[    9.599994] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[    9.610973] ath10k_pci 0000:01:00.0: firmware ver 10.2.4-1.0-00047 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 35bd9258
[    9.681115] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[   10.829298] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
[   10.957594] ath: EEPROM regdomain: 0x0
[   10.957624] ath: EEPROM indicates default country code should be used
[   10.957629] ath: doing EEPROM country->regdmn map search
[   10.957636] ath: country maps to regdmn code: 0x3a
[   10.957641] ath: Country alpha2 being used: US
[   10.957648] ath: Regpair used: 0x3a
2

This isn't necessarily an issue.

Many client (STA mode) devices will sleep the radios for power savings. The radios will wake up periodically so the OS can check if there are any incoming connections that need to be handled (and of course any outbound ones that were scheduled). Then the radio will sleep again. This happens rapidly enough that it appears to be always-on at human time scales, but it can save a lot of power by being off a good amount of the time. This is critical for battery powered devices (phones/tablets/laptops), but even mains-powered devices will do this for energy efficiency.

3

Shouldn't it detect 1rps ICMP to be "frequent enough" and stay alive?

4

1 second is an eternity in computer time. If you have a 1GHz processor, it's clocking a billion times in 1 second. If it can sleep the radio for say half of that, it's a considerable energy savings.

You could run a speedtest from the client and then at the same time run your ping tests to the client, and you should theoretically see a lower latency (although the radio will be busy, so there will still be some added latency as well as variability, but it should average lower than what you're seeing when the device is mostly idle).