設定しました
uci set simple-tc.mesh_vpn.limit_ingress=10000
uci set simple-tc.mesh_vpn.limit_egress=1000
uci commit simple-tc && /etc/init.d/tunneldigger restart
これらの設定で、スピードテストを実行すると、ダウンロード速度が3 MBit / s未満になります(予想どおり、アップロード速度は1 MBit / sになります)。
入力制限が30000
場合、ダウンロード速度は最大5 MBit / sに増加します。
simple-tcをオフにすると、ダウンロード用に25 MBit / sが得られます(私のDSL回線には30 MBit / sがあるので、予想どおりです)。
simple-tcは、ダウンロード速度を本来よりもはるかに遅くしているようです。 これらのテスト中にデバイスの負荷を調べましたが、常に50%を超えるアイドル状態でした。
これは、トンネルディガー/ l2tpベースのネットワークで、WR841N / NDv10とGluonv2018.1.8に基づくファームウェアを使用します。
TL; DR:イングレスフィルターが不良です。動作は既知です。
VPNピアがトラフィックを送信する速度を制御する方法はありません。 このような機能は、VPNソフトウェア、または制限を送信して反対側に出力フィルターをインストールするVPNの上のレイヤーに実装する必要があります。
イングレスフィルターが行う唯一のことは、制限を超えたときにパケットをドロップし、TCP接続が正常に動作してスループットを低下させることを期待することです。 非TCPプロトコルの場合、状況はさらに悪化します。これは、多くの場合、どのような種類の制御も行わないためです(したがって、イングレスフィルターが作動するとパケット損失が発生するだけです)。 また、TCPの場合でも、特に複数の並列TCPストリームがある場合、一部のTCP実装では、パケット損失が存在する場合の動作が非常に悪くなる可能性があります。
そうですか。 したがって、トンネルディガーがゲートウェイ側のブローカーに出力フィルタリングを実行するように指示することが必要です。 それがどのように理にかなっているのかがわかります。 :)
トンネル掘りの情報源などのどこかで、そのためのTODOを見たことさえあると思います。
tunneldiggerでそのサポートを追加することを検討できます。 simple-tcは、その点でVPNクライアントとの連携をサポートしていますか?
Tunneldiggerはすでにそのサポートを持っています(クライアントの-Lフラグにより、サーバーは要求されたダウンストリーム帯域幅制限を設定します)。 Gluon側のサポートが欠落しているだけで、実際にそのフラグをtunneldiggerに渡すことができます。
d87c4b521b2e891155241c01b98a7ac90a8883b9で修正済み
素晴らしい、どうもありがとう!