Estaba probando una conexión WebSocket cuando noté inquietud; Algunos paquetes TCP se estaban retrasando. Entonces comencé a hacer ping al destino. Tan pronto como lo hice, los paquetes TCP ya no se retrasaron, extraño. Dejé de hacer ping; Empecé a sentirme nervioso de nuevo.
Parece que si supero un cierto umbral de tráfico, entonces el adaptador de red ya no tiene fluctuación; por debajo de ese umbral, sin embargo, parece retrasar los paquetes.
Lo probé nuevamente haciendo ping a otros sitios no relacionados con la ruta de conexión WebSocket y eso también elimina la inquietud. También sucede independientemente del tráfico y la ruta, por ejemplo, si transmito datos desde un destino diferente y pruebo la conexión WS, no hay fluctuaciones. Esto parece indicar que es específico de la interfaz de red local, ya que esa es la única constante aquí.
Me parece que hay algo de almacenamiento en búfer entre la NIC y la pila de IP y el búfer no se vacía adecuadamente en volúmenes bajos.
He examinado el tamaño del búfer circular (cola de controladores), todos están configurados en 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
¿Esto es normal? Supongo que los buffers QDisc se almacenarán en su lugar. En todo caso, un tamaño de cola más pequeño daría como resultado una menor latencia, pero con paquetes descartados que no veo.
Sé que BQL (colas de límite de bytes) son una característica del almacenamiento en búfer entre la pila de IP y la NIC, pero no veo cómo se comportaría como lo estoy viendo.
Entonces mi pregunta es; ¿Existe algún algoritmo de cola conocido en la pila de red de Linux que pueda limitar el tráfico en volúmenes bajos a través de la NIC pero que ya no limite el tráfico en volúmenes más altos?
Respuesta1
Esto se debió a la administración activa de energía en la NIC inalámbrica.
La ejecución de este comando que desactiva la administración de energía para la NIC solucionó este problema:
sudo iwconfig wlp3s0 power off
Parece que la administración de energía para esta NIC en particular se activó con un tiempo de espera extremadamente bajo. Por ejemplo, ningún tráfico transmitido durante aproximadamente 200 ms pondrá la NIC en modo de bajo consumo, lo que significaba que la NIC tenía que activarse constantemente con volúmenes de tráfico bajos, lo que provocaba retrasos en los paquetes.