Eu estava testando uma conexão WebSocket quando percebi instabilidade; alguns pacotes TCP estavam atrasados. Então comecei a fazer ping no destino. Assim que fiz isso os pacotes TCP não estavam mais atrasados, estranho. Parei de pingar; Comecei a ficar nervoso novamente.
Parece que se eu ultrapassar um determinado limite de tráfego, o adaptador de rede não terá mais instabilidade; abaixo desse limite, porém, parece atrasar os pacotes.
Testei-o novamente executando ping em outros sites não relacionados ao caminho de conexão do WebSocket e isso também remove o jitter. Isso também acontece independentemente do tráfego e do caminho, por exemplo, se eu transmitir dados de um destino diferente e testar a conexão WS, não haverá instabilidade. Isso parece indicar que é específico da interface de rede local, pois é a única constante aqui.
Parece-me que há algum buffer entre a NIC e a pilha de IP e o buffer não está sendo liberado adequadamente em volumes baixos
Eu olhei para o tamanho do buffer de anel (fila do driver), todos eles estão definidos como 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
Isso é normal? Presumo que os buffers QDisc estarão em buffer. No mínimo, um tamanho de fila menor resultaria em menos latência, mas com pacotes descartados que não estou vendo.
Eu sei que BQL (Byte Limit Queues) é um recurso de buffer entre a pilha IP e a NIC, mas não consigo ver como isso se comportaria como estou vendo.
Então minha pergunta é; existe algum algoritmo de enfileiramento conhecido na pilha de rede do Linux que possa estar limitando em volumes baixos de tráfego na NIC, mas não limita mais o tráfego em volumes mais altos?
Responder1
Isso foi causado pelo gerenciamento ativo de energia na NIC sem fio.
A execução deste comando que desativa o gerenciamento de energia da NIC corrigiu o seguinte:
sudo iwconfig wlp3s0 power off
Parece que o gerenciamento de energia desta NIC específica ficou ativo com um tempo limite extremamente baixo. Por exemplo, nenhum tráfego transmitido por aproximadamente 200 ms colocará a NIC no modo de baixo consumo de energia, o que significava que a NIC precisava ser constantemente acordada com baixos volumes de tráfego, resultando em pacotes atrasados.