最終更新: megaron_sanders 2016年03月13日(日) 20:53:23履歴
tc は非常に細かい制御が可能なのですが、記述がその分複雑になります。 そんなことじゃなくインタフェースに対してシェーピングしたいだけだったので、さっくりやってさっくり終わります。
たとえば超適当に、
tc qdisc add dev eth0 root tbf limit 2Mb rate 5Mbps burst 1Mb
こんな感じで設定します。 設定している値の根拠は全然ありません。 ここでは「rate 5Mbps」が重要です。
となるわけです。 実際設定して見てみましたが、iptablesよりしっかり効いてていい感じに制御できます。
tc qdisc add dev eth0 root tbf limit 2Mb rate 5Mbps burst 1Mb
こんな感じで設定します。 設定している値の根拠は全然ありません。 ここでは「rate 5Mbps」が重要です。
5Mbytes per sec = 5 * 8 Mbits per sec = 40Mbps
となるわけです。 実際設定して見てみましたが、iptablesよりしっかり効いてていい感じに制御できます。
ちなみに今回はトークンバケットフィルタ「TBF」って一番簡単なキューイング処理方法を採用してます。 トークンをバケツに入れて、これをバケツリレーみたいに送るイメージで帯域制御を実現しているようです。 他にも制御方法はあるのですが、帯域制御をするだけなので、これで十分です。 というかそれ以上の高機能なやつを使うといたずらにOSの負荷が高くなると思うので多分これが最適です。
上だけだと何なので、ちょっと tc を調べました。 値の決め方は多分以下のようなイメージかな?
参考は「Linux Advanced Routing & Traffic Control HOWTO」の「9.2. シンプルな、クラスレスのキューイング規則」です。 参考元の方に怒られるレベルの理解だと思うので、参考元見てね。
burstの値をrateとの関係を変えていくと面白いデータが取れるかもしれない....と思ったけど、やらない。
上だけだと何なので、ちょっと tc を調べました。 値の決め方は多分以下のようなイメージかな?
参考は「Linux Advanced Routing & Traffic Control HOWTO」の「9.2. シンプルな、クラスレスのキューイング規則」です。 参考元の方に怒られるレベルの理解だと思うので、参考元見てね。
- limit …… 桶の大きさ。 送りたい水(データ)があるときはこの桶に入れる。 なのであまり小さいと溢れてしまってデータがすっ飛んでしまう(q破棄される)。 かといってあまり大きいと取るのに苦労するのであまりおおきいのも困り者(遅延が大きくなる)。
- burst …… 桶に溜まった水(データ)を汲み出す汲み桶の大きさ。 burst とか書いてあるので超過分のトラフィック容量のことかと思ったがどうやらそうではなく、この意味のようだ。
- rate …… 汲み桶で汲み取る水(データ)の容量(速度)のこと。 1秒間に何回桶で汲み取るかについては多分割り込み処理の度だとおもうので、汲み桶の数と思ったらいいか。
burstの値をrateとの関係を変えていくと面白いデータが取れるかもしれない....と思ったけど、やらない。
コメントをかく