WiFi adapter is delaying packets when low throughput

Question

I was testing a WebSocket connection when I noticed jitter; some TCP packets were getting delayed. So I started pinging the destination. As soon as I did that the TCP packets were no longer getting delayed, weird. I stopped pinging; I started getting jitter again.

It seems like that if I go beyond a certain threshold of traffic then the network adapter no longer has jitter, below that threshold however it seems to delay packets.

I tested it again by pinging other sites unrelated to the WebSocket connection path and that too removes the jitter. It also happens regardless of the traffic and path e.g if I stream data from a different destination and test the WS connection there's no jitter. This seems to indicate it's specific to the local network interface as that's the only constant here.

It appears to me like there's some buffering going on between the NIC and the IP stack and the buffer isn't being flushed appropriately at low volumes

I've looked into the ring buffer size (driver queue) they are all set to 0:

Ring parameters for wlp3s0:
Pre-set maximums:
RX:     0
RX Mini:    0
RX Jumbo:   0
TX:     0
Current hardware settings:
RX:     0
RX Mini:    0
RX Jumbo:   0
TX:     0

Is this normal? I assume the QDisc buffers will be buffering instead. If anything a smaller queue size would result in less latency but with dropped packets which I'm not seeing.

I know BQL (Byte Limit Queues) are a feature of the buffering between IP stack and NIC but I can't see how that would behave like I'm seeing.

So my question is; is there any known queuing algorithm in the network stack of Linux that could be throttling at low volumes of traffic over the NIC but no longer throttles traffic at higher volumes?

Answer 1

This was caused by active power management on the Wireless NIC.

Running this command which switches off power management for the NIC fixed this:

sudo iwconfig wlp3s0 power off

It seems the power management for this particular NIC became active with an extremely low timeout. E.g no traffic transmitted for ~200 ms will put the NIC into low power mode this meant that the NIC was constantly having to be woken up at low traffic volumes resulting in delayed packets.