WMM and delays on TP-LINK routers

I was quite puzzled recently when, after unpacking a TP-LINK TL-WR740N router, plugging it in and configuring a wireless network on it, ICMP ping delays between the router and a laptop connected to it via Wi-Fi were reaching 100 milliseconds, despite a mere distance of a couple of meters between the two devices (without any obstacles). Changing channels and supported speeds didn’t help. It turned out that the reason was WMM (Wi-Fi MultiMedia) which is enabled by default.

WMM is a standard which is supposed to provide proper QoS level to various services like VoIP or video running via Wi-Fi. Apparently ICMP pings are qualified as low priority traffic (whether that makes sense or not is questionable), which results in getting the following when pinging the router from a laptop placed 3 meters away:

Reply from 192.168.67.1: bytes=32 time=3ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=3ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=49ms TTL=64
Reply from 192.168.67.1: bytes=32 time=73ms TTL=64
Reply from 192.168.67.1: bytes=32 time=92ms TTL=64
Reply from 192.168.67.1: bytes=32 time=115ms TTL=64
Reply from 192.168.67.1: bytes=32 time=33ms TTL=64
Reply from 192.168.67.1: bytes=32 time=55ms TTL=64
Reply from 192.168.67.1: bytes=32 time=77ms TTL=64
Reply from 192.168.67.1: bytes=32 time=98ms TTL=64
Reply from 192.168.67.1: bytes=32 time=17ms TTL=64
Reply from 192.168.67.1: bytes=32 time=39ms TTL=64
Reply from 192.168.67.1: bytes=32 time=60ms TTL=64
Reply from 192.168.67.1: bytes=32 time=82ms TTL=64
Reply from 192.168.67.1: bytes=32 time=103ms TTL=64

After disabling WMM (for the TL-WR740N router: Wireless → Wireless Advanced → uncheck Enable WMM):

Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=3ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64
Reply from 192.168.67.1: bytes=32 time=1ms TTL=64

I don’t know if WMM causes similar effects on other vendors’ hardware, but that possibility is worth considering if your pings are suspiciously high while “everyday” services work flawlessly.