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?