Ich habe gerade eine WebSocket-Verbindung getestet, als mir Jitter auffiel; einige TCP-Pakete wurden verzögert. Also begann ich, das Ziel anzupingen. Sobald ich das tat, wurden die TCP-Pakete nicht mehr verzögert, komisch. Ich hörte auf zu pingen; das Jitter begann wieder.
Es scheint, als ob der Netzwerkadapter kein Jitter mehr aufweist, wenn ich einen bestimmten Datenverkehrsschwellenwert überschreite. Unterhalb dieses Schwellenwerts scheint es jedoch zu Paketverzögerungen zu kommen.
Ich habe es noch einmal getestet, indem ich andere Sites angepingt habe, die nichts mit dem WebSocket-Verbindungspfad zu tun haben, und auch das beseitigt das Jitter. Es tritt auch unabhängig von Datenverkehr und Pfad auf, d. h. wenn ich Daten von einem anderen Ziel streame und die WS-Verbindung teste, gibt es kein Jitter. Dies scheint darauf hinzudeuten, dass es spezifisch für die lokale Netzwerkschnittstelle ist, da dies hier die einzige Konstante ist.
Es scheint mir, als ob zwischen der Netzwerkkarte und dem IP-Stack eine Pufferung stattfindet und der Puffer bei niedrigen Volumina nicht richtig geleert wird.
Ich habe mir die Ringpuffergröße (Treiberwarteschlange) angesehen und sie ist alle auf 0 eingestellt:
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
Ist das normal? Ich gehe davon aus, dass stattdessen die QDisc-Puffer puffern. Wenn überhaupt, würde eine kleinere Warteschlangengröße zu weniger Latenz führen, allerdings mit verlorenen Paketen, die ich nicht sehe.
Ich weiß, dass BQL (Byte Limit Queues) eine Funktion der Pufferung zwischen IP-Stapel und NIC sind, aber ich kann mir nicht vorstellen, wie sich das so verhalten würde, wie ich es sehe.
Meine Frage ist also: Gibt es im Netzwerkstapel von Linux einen bekannten Warteschlangenalgorithmus, der bei geringem Datenverkehr über die Netzwerkkarte eine Drosselung bewirken könnte, bei höherem Datenverkehr jedoch nicht mehr erfolgt?
Antwort1
Dies wurde durch aktives Energiemanagement der Wireless-NIC verursacht.
Das Ausführen dieses Befehls, der die Energieverwaltung für die Netzwerkkarte ausschaltet, hat das folgende Problem behoben:
sudo iwconfig wlp3s0 power off
Es scheint, dass die Energieverwaltung für diese bestimmte Netzwerkkarte mit einem extrem kurzen Timeout aktiviert wurde. Wenn beispielsweise für ca. 200 ms kein Datenverkehr übertragen wird, wird die Netzwerkkarte in den Energiesparmodus versetzt. Dies bedeutet, dass die Netzwerkkarte bei geringem Datenverkehr ständig aufgeweckt werden muss, was zu verzögerten Paketen führt.