WebSocket 接続をテストしていたとき、ジッターに気づきました。一部の TCP パケットが遅延していました。そこで、宛先に ping し始めました。するとすぐに、TCP パケットの遅延がなくなりました。不思議です。ping をやめると、再びジッターが発生し始めました。
トラフィックが一定のしきい値を超えると、ネットワーク アダプタにジッターがなくなるようですが、そのしきい値を下回ると、パケットが遅延するようです。
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 (バイト制限キュー) は IP スタックと NIC 間のバッファリング機能であることはわかっていますが、それがどのように動作するのかはわかりません。
そこで私の質問は、Linux のネットワーク スタックに、NIC 経由のトラフィック量が少ないときにはスロットルできるが、トラフィック量が多いときにはスロットルしなくなる、既知のキューイング アルゴリズムがあるかどうかです。
答え1
これは、ワイヤレス NIC のアクティブな電源管理によって発生しました。
NIC の電源管理をオフにするこのコマンドを実行すると、この問題は修正されました。
sudo iwconfig wlp3s0 power off
この特定の NIC の電源管理が、非常に短いタイムアウトでアクティブになったようです。たとえば、約 200 ミリ秒間トラフィックが送信されないと、NIC は低電力モードになります。つまり、トラフィック量が少ないときに NIC を常に起動する必要があり、パケットが遅延します。