처리량이 낮을 때 WiFi 어댑터가 패킷을 지연시킵니다.

처리량이 낮을 때 WiFi 어댑터가 패킷을 지연시킵니다.

WebSocket 연결을 테스트하고 있을 때 지터가 발견되었습니다. 일부 TCP 패킷이 지연되었습니다. 그래서 목적지에 핑을 보내기 시작했습니다. 내가 그렇게하자마자 TCP 패킷이 더 이상 지연되지 않았습니다. 이상했습니다. 나는 핑을 중단했습니다. 나는 다시 불안해지기 시작했다.

특정 트래픽 임계값을 초과하면 네트워크 어댑터에 더 이상 지터가 없지만 해당 임계값 아래에서는 패킷이 지연되는 것처럼 보입니다.

WebSocket 연결 경로와 관련이 없는 다른 사이트에 ping을 실행하여 다시 테스트했는데, 그것도 지터를 제거했습니다. 또한 트래픽과 경로에 관계없이 발생합니다. 예를 들어 다른 대상에서 데이터를 스트리밍하고 WS 연결을 테스트하면 지터가 없습니다. 이는 여기서 유일한 상수이므로 로컬 네트워크 인터페이스에만 해당됨을 나타내는 것 같습니다.

NIC와 IP 스택 사이에 버퍼링이 발생하고 낮은 볼륨에서는 버퍼가 적절하게 플러시되지 않는 것 같습니다.

링 버퍼 크기(드라이버 큐)를 조사했는데 모두 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

이게 정상인가요? 나는 QDisc 버퍼가 대신 버퍼링할 것이라고 가정합니다. 대기열 크기가 작을수록 대기 시간은 줄어들지만 보이지 않는 패킷이 삭제됩니다.

BQL(Byte Limit Queues)이 IP 스택과 NIC 간의 버퍼링 기능이라는 것을 알고 있지만 이것이 내가 보고 있는 것처럼 어떻게 작동할지 모르겠습니다.

그래서 내 질문은 다음과 같습니다. Linux의 네트워크 스택에 NIC를 통한 낮은 트래픽 볼륨에서는 제한할 수 있지만 더 이상 높은 볼륨에서는 트래픽을 제한하지 않는 알려진 대기열 알고리즘이 있습니까?

답변1

이는 무선 NIC의 활성 전원 관리로 인해 발생했습니다.

NIC의 전원 관리를 끄는 이 명령을 실행하면 이 문제가 해결되었습니다.

sudo iwconfig wlp3s0 power off

이 특정 NIC에 대한 전원 관리가 매우 짧은 시간 초과로 활성화된 것 같습니다. 예를 들어 ~200ms 동안 트래픽이 전송되지 않으면 NIC가 저전력 모드로 전환됩니다. 이는 NIC가 낮은 트래픽 볼륨에서 지속적으로 깨어나야 패킷이 지연된다는 의미입니다.

관련 정보