インターネット回線に何らかのトラフィック管理を追加したいと思います。たくさんのドキュメントを読んだ後、HFSCは私には複雑すぎると思います（すべての曲線を理解しているわけではありません。正しく理解できないと思います）。CBQはお勧めしません。基本的にHTBはほとんどの人のために行きます。
私たちの内部ネットワークには3つの「セグメント」があり、それらの間で帯域幅を多かれ少なかれ均等に共有したいと思っています（少なくとも最初は）。さらに、少なくとも3種類のトラフィック（リアルタイムトラフィック、標準トラフィック、バルクトラフィック）に従ってトラフィックを優先する必要があります。帯域幅の共有は、リアルタイムトラフィックを可能な限り常にプレミアムトラフィックとして扱う必要があるという事実ほど重要ではありませんが、他のトラフィッククラスが不足することはありません。
問題は、何がより意味があり、リアルタイムのスループットが向上するかを保証することです。
セグメントごとに1つのクラスを作成し、それぞれが同じレートを持ち（HTB開発者によると、葉ではないクラスでは優先度は関係ありません）、これらの各クラスには、3つの優先度レベル（異なる優先度）の3つのサブクラス（葉）がありますと異なるレート）。
優先度レベルごとに1つのクラスがあり、それぞれに異なるレートがあり（やはり優先度は関係ありません）、セグメントごとに1つずつ、3つのサブクラスがありますが、リアルタイムクラスの3つすべてが一括で最高のプリオ、最低のプリオを持ちますクラスなど。
次のASCIIアートイメージを使用して、これをより明確にするようにします。
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Normal Prio
| +--> Segment A
| +--> Segment B
| +--> Segment C
|
+--> Low Prio
+--> Segment A
+--> Segment B
+--> Segment C
ケース1はほとんどの人のやり方と同じように見えますが、HTBの実装の詳細を正しく読んでいない限り、ケース2の方が優先順位が高くなる可能性があります。
HTBマニュアルによると、クラスがそのレートに達した場合、そのクラスは親から借りることがあり、借りるときは、優先度の高いクラスが常に最初に提供される帯域幅を取得することになります。ただし、優先度に関係なく、より低いツリーレベルで使用可能な帯域幅を持つクラスは、より高いツリーレベルのクラスよりも常に優先されるとも述べています。
次の状況を想定してみましょう。セグメントCはトラフィックを送信していません。セグメントAはできる限り速く（リンクのみを飽和させるのに十分）リアルタイムトラフィックのみを送信し、セグメントBはできる限り速く（やはり、完全なリンクのみを飽和させるのに十分）バルクトラフィックのみを送信します。何が起こるか？
ケース1：
セグメントA-> High PrioとセグメントB-> Low Prioの両方に送信するパケットがあります。A-> High Prioの方が優先順位が高いため、レートに達するまで常に最初にスケジュールされます。現在はセグメントAから借入を試みていますが、セグメントAはより高いレベルにあり、セグメントB->低優先順位はまだレートに達していないため、このクラスが最初に提供され、レートに達してから借入を希望するまでセグメントB.両方がレートに達すると、両方が同じレベルになり、セグメントA->高優先順位が再び勝ち、セグメントAのレートに達するまで、ルートから借用しようとします（これはセグメントCは保証されたトラフィックをまったく使用していないため、十分な量のトラフィックを確保できますが、セグメントB->低優先度もルートレベルに到達するまで待機する必要があります。それが起こると、
ケース2：
高優先度->セグメントAと低優先度->セグメントBの両方に送信するパケットがあり、ここでも高優先度->セグメントAの方が優先度が高いので勝ちます。レートに達すると、帯域幅に余裕があるHigh Prioから借用しようとしますが、より高いレベルにあるため、Low Prio-> Segment Bが再びレートに達するまで待機する必要があります。両方がレートに達し、両方とも借りる必要がある場合、High Prio-> Segment AはHigh Prioクラスのレートに達するまで再び勝ちます。それが発生すると、ルートから借用しようとしますが、これは十分な帯域幅が残っています（Normal Prioのすべての帯域幅は現時点では未使用です）が、低Prio-> Segment Bが低Prioクラスとルートからも借りようとします。最後に、両方のクラスがルートから借用しようとし、優先度が考慮され、高優先度->
どちらの場合も、借りることができる帯域幅が十分残っていても、リアルタイムトラフィックがバルクトラフィックを待たなければならない場合があるため、どちらも最適ではないようです。ただし、ケース2では、バルクトラフィックレートに達するまで待機するだけでよいため、リアルタイムトラフィックはケース1よりも少なくなるように見えます。これは、セグメント全体のレートよりも低い可能性が高いです。 1は、待機する必要があるレートです。それとも私はここで完全に間違っていますか？
優先度qdiscを使用して、さらに単純なセットアップについて考えました。しかし、プライオリティキューは、なんらかの制限がないと飢餓を引き起こすという大きな問題があります。飢餓は許されません。もちろん、各優先度クラスにTBF（トークンバケットフィルター）を挿入してレートを制限し、飢餓を回避することができますが、そうすると、他のすべての優先度クラスであっても、単一の優先度クラスがそれ自体でリンクを飽和させることはできなくなります空の場合、TBFはそれを防止します。また、現時点で他のクラスがそれを必要としないクラスがラインの帯域幅の100％を取得しないのはなぜですか？
このセットアップに関するコメントやアイデアはありますか？標準のtc qdiscsを使用するのはとても難しいようです。プログラマーとして、自分でスケジューラーを作成するだけなら簡単な作業でした（許可されていません）。