WiFiアダプタはスループットが低いときにパケットを遅延させます

WiFiアダプタはスループットが低いときにパケットを遅延させます

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 を常に起動する必要があり、パケットが遅延します。

関連情報