これらのキューには、それぞれ長所と短所があります。 これらのすべてが、完全にテストされているというわけではありません。
カーネルは、パケットのいわゆる「サービスのタイプ (Type of Service)」フラグを 尊重し、「最小遅延 (minimum delay)」パケットをバンド 0 に入れるよう計らいます。
pfifo_fast qdisc は出来合いのデフォルトですから、 ユーザによる設定はできません。 ここではデフォルトでどのように設定されているかを示します。
パケットの優先具合が、カーネルによって、どのバンドに対応付けられるかを決めます。 対応付けはパケットの TOS に従って決まります。TOS は以下のようなものです。
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TOS | MBZ | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ |
TOS の 4 ビット (「TOS フィールド」) は次のように定義されています。
Binary Decimcal Meaning ----------------------------------------- 1000 8 Minimize delay (md) 0100 4 Maximize throughput (mt) 0010 2 Maximize reliability (mr) 0001 1 Minimize monetary cost (mmc) 0000 0 Normal Service |
TOS Bits Means Linux Priority Band ------------------------------------------------------------ 0x0 0 Normal Service 0 Best Effort 1 0x2 1 Minimize Monetary Cost 1 Filler 2 0x4 2 Maximize Reliability 0 Best Effort 1 0x6 3 mmc+mr 0 Best Effort 1 0x8 4 Maximize Throughput 2 Bulk 2 0xa 5 mmc+mt 2 Bulk 2 0xc 6 mr+mt 2 Bulk 2 0xe 7 mmc+mr+mt 2 Bulk 2 0x10 8 Minimize Delay 6 Interactive 0 0x12 9 mmc+md 6 Interactive 0 0x14 10 mr+md 6 Interactive 0 0x16 11 mmc+mr+md 6 Interactive 0 0x18 12 mt+md 4 Int. Bulk 1 0x1a 13 mmc+mt+md 4 Int. Bulk 1 0x1c 14 mr+mt+md 4 Int. Bulk 1 0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1 |
第 4 列は Linux カーネルによる TOS ビット列の解釈です。 どの優先度にマップされるかを示しています。
最後の列は、デフォルトの優先度マップ (priomap) の結果です。 コマンドラインでは、デフォルトの優先度マップは次のようになります。
1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1 |
この表は RFC1349 (詳細は直接こちらを) から取ったもので、 各アプリケーションがどのように TOS ビットを設定すると良いかについて示してあります。
TELNET 1000 (minimize delay) FTP Control 1000 (minimize delay) Data 0100 (maximize throughput) TFTP 1000 (minimize delay) SMTP Command phase 1000 (minimize delay) DATA phase 0100 (maximize throughput) Domain Name Service UDP Query 1000 (minimize delay) TCP Query 0000 Zone Transfer 0100 (maximize throughput) NNTP 0001 (minimize monetary cost) ICMP Errors 0000 Requests 0000 (mostly) Responses <same as request> (mostly) |
TBF は非常に正確で、ネットワークとプロセッサへの負荷も軽いです。 単純にインターフェースの速度を落としたいと思ったときには、 まず最初にこの利用を考えてみるべきです。
後ろの 2 シナリオがとても重要です。 これらは、このフィルタを通過するデータのバンド幅を、 管理者が制御できることを意味しているからです。
トークンが溜まっていくと、制限を越えたデータバーストも、 短いものならロスなしに通過できますが、 過負荷状態が続くとパケットはだんだん遅延していき、ついには破棄されます。
ただし実際の実装では、トークンが対応しているのはバイトであり、 パケットではありません。
ほとんど変更の必要はないでしょうが、 TBF にも調整つまみはついています。 まず、つねに指定できるパラメータです:
バケツにトークンが入っていて、これを空にすることが許されるとき、 デフォルトではこの作業は無限の速度で行われます。 これがまずい場合には、以下のパラメータを使って下さい。
# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540 |
上記の実行例では、モデムのキューが必要ない程度にまで、 送信速度を落としています。これでキューは Linux 上にあり、 これに対して制限を課すことができます。
220kbit は、あなたの環境の「実際の」速度 (マイナス数パーセント) にしてください。手持ちのモデムが非常に高速なら、'burst' を少々増やしてください。
特に、ケーブルモデムや DSL ルータに向かうイーサネットに対して SFQ を設定するのは、他の制限を行わないならば的外れです。
接続速度と実効速度とが同じデバイス (電話線のモデム) に対しては、 この設定を行うと公平性の向上が期待できます:
# tc qdisc add dev ppp0 root sfq perturb 10 # tc -s -d qdisc ls qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec Sent 4812 bytes 62 pkts (dropped 0, overlimits 0) |