解決策 1:
HFSC とそのいとこに関する論文を読むことは、それを理解する良い方法ではありません。 HFSC 論文の主な目的は、その主張の厳密な数学的証明を提供することであり、それがどのように機能するかを説明することではありません。実際、HFSC の論文だけではそれがどのように機能するかを理解することはできません。参照している論文も読む必要があります。主張またはその証明に問題がある場合は、論文の著者に連絡するのが良い考えかもしれません。さもなければ、彼らがあなたからの連絡に興味を持つとは思えません.
HFSC のチュートリアルを作成しました。以下の説明が明確でない場合は、読んでください。
<ブロック引用>リアルタイム カーブが必要な理由は何ですか? A1、A2、B1、B2 がすべて 128 kbit/s のリンク共有であると仮定すると (どちらにもリアルタイム曲線はありません)、ルートに 512 kbit/s の配信がある場合 (および A と A およびB はもちろん両方とも 256 kbit/s です)、そうですか? A1 と B1 に 128 kbit/s のリアルタイム カーブを追加する必要があるのはなぜですか?これは何に役立ちますか?この 2 つの優先順位を高くするには?元の論文によると、曲線を使用して優先順位を高くすることができます。それが HFSC のすべてです。両方のクラスに [256kbit/s 20ms 128kbit/s] の曲線を与えることで、どちらも自動的に A2 と B2 の 2 倍の優先度を持ちます (まだ平均 128 kbit/s しか得られません)
リアルタイム曲線とリンク共有曲線は、さまざまな方法で評価されます。リアルタイム曲線は、クラスが全履歴を通じて行ったことを考慮に入れます。正確な帯域幅と遅延の割り当てを提供するには、これを行う必要があります。マイナス面は、ほとんどの人が直感的に 公正 と考えるものではありません .リアルタイムでは、クラスが帯域幅を借用した場合、他の誰かがそれを要求したときにペナルティが課せられます。これは、リアルタイムの保証の下では、クラスが帯域幅を長期間取得できないことを意味します。これは、誰もそれを望んでいないときにそれを使用したためです。
リンクの共有は公平であり、予備の帯域幅を使用することでクラスが不利になることはありません。ただし、これは強力な遅延保証を提供できないことを意味します。
遅延保証の提供からリンク共有を分離することは、HFSC が持ち込む新しいものであり、この論文は冒頭の文で次のように述べています。 この論文では、リンクと分離された遅延 (優先度) と帯域幅の割り当てにより、共有および保証されたリアルタイム サービス。 その文のキーワードは切り離されています。つまり、未使用の帯域幅を ls で共有する方法を指定し、rt で必要なリアルタイム保証 (レイテンシー保証ともいう) を指定する必要があることを意味します。この 2 つは直交しています。
<ブロック引用>リアルタイム帯域幅はリンク共有帯域幅にカウントされますか?
はい。 HFSC の論文では、クラスがバックログになった (つまり、送信待ちのパケットがある) ため、クラスが送信したものに関して帯域幅を定義しています。 rt と ls の唯一の違いは、クラスがバックログになるたびに rt が前方を検索し、そのセットから最低保証帯域幅を計算するのに対し、リンク共有はクラスが最後にバックログになった時点からのみ検索することです。そのため、rt は ls よりも多くのバイトを考慮しますが、ls が考慮するすべてのバイトは rt でも考慮されます。
<ブロック引用>上限曲線はリアルタイムにも適用されますか?リンク共有のみに適用されますか?それとも両方に適用されますか?
上限は、リアルタイム条件を満たすためにパケットの送信を停止しません。リアルタイム条件で送信されたパケットは依然として上限に向かってカウントされるため、将来、リンク共有条件で送信されるパケットが遅延する可能性があります。これは、リアルタイムとリンク共有のもう 1 つの違いです。
<ブロック引用>A2 と B2 が両方とも 128 kbit/s であると仮定すると、A1 と B1 が 128 kbit/s リンク共有のみであるか、または 64 kbit/s リアルタイムで 128 kbit/s リンク共有であるかに違いはありますか?違いは?
はい、違いはあります。上で説明したように、リアルタイムを使用する場合、遅延は保証されますが、リンクは公平に共有されず (特に、クラスは帯域幅不足に陥る可能性があります)、上限は適用されません。リンク共有を使用する場合、遅延は保証されませんが、リンク共有は公正であり、枯渇のリスクはなく、上限が適用されます。リアルタイムはリンク共有の前に常にチェックされますが、必ずしもリンク共有が無視されるわけではありません。これは、パケットのカウント方法が異なるためです。履歴はリアルタイムで考慮されるため、パケットはリアルタイム保証を満たす必要はないかもしれませんが (履歴からカウントされるため)、履歴パケットを無視するため、リンク共有を満たすために必要です。
<ブロック引用>別のリアルタイム カーブを使用してクラスの優先度を上げる場合、なぜ「カーブ」が必要なのですか?リアルタイムがフラット値でなく、リンク共有もフラット値でないのはなぜですか?なぜ両方が曲線なのですか？クラスごとにその種の属性が 1 つしかないため、元の論文では曲線の必要性は明らかです。しかし今、3 つの属性 (リアルタイム、リンクシェア、上限) を持っているのに、それぞれに曲線が必要なのはなぜでしょうか?曲線の形状 (平均帯域幅ではなく、勾配) をリアルタイムとリンク共有トラフィックで異なるものにする必要があるのはなぜですか?
リアルタイム制御の曲線により、特定のトラフィック クラス (VOIP など) の短い遅延と、他のトラフィック クラス (電子メールなど) の遅延を交換することができます。リアルタイムの制約の下で送信するパケットを決定するとき、HFSC は最初に送信を完了するパケットを選択します。ただし、リンクの帯域幅を使用してこれを計算するのではなく、リアルタイム曲線によって割り当てられた帯域幅を使用します。したがって、同じ長さの VOIP パケットと電子メール パケットがあり、VOIP パケットが電子メールの凹型曲線を 10 倍上回る凸型曲線を持っている場合、最初の電子メール パケットの前に 10 個の VOIP パケットが送信されます。しかし、これはバースト時間でのみ発生します。バースト時間は、せいぜいいくつかのパケットを送信するのにかかる時間、つまりミリ秒です。その後、VOIP曲線は平坦化するはずであり、VOIPはしばらく後退しない限り、将来のブーストを得ることができません（VOIPが低帯域幅アプリケーションであることを考えると、そうなるはずです）.これらすべての最終的な結果として、最初の 2 つの VOIP パケットが他の何よりも高速に送信されるようになり、電子メールの遅延が大きくなる代わりに VOIP の遅延が低くなります。
先に述べたように、リンク共有は履歴を参照しないため、遅延を保証することはできません。 VOIP のようなリアルタイム トラフィックには、確固たる保証が必要です。ただし、平均して、凸曲線を共有するリンクは、依然としてトラフィックの遅延を増加させます。それは保証されていません。メール経由の Web トラフィックなど、ほとんどの場合はこれで問題ありません。
<ブロック引用>利用可能なわずかなドキュメントによると、リアルタイムの曲線値は内部クラス (クラス A および B) では完全に無視され、リーフ クラス (A1、A2、B1、B2) にのみ適用されます。それが本当なら、ALTQ HFSC サンプル構成 (3.3 サンプル構成を検索) が内部クラスにリアルタイム曲線を設定し、それらがそれらの内部クラスの保証レートを設定すると主張するのはなぜですか?まったく無意味じゃないですか。 (注:pshare は ALTQ でリンク共有曲線を設定し、リアルタイム曲線を調整します。これは、サンプル構成の上の段落で確認できます)。
ドキュメントは正しいです。階層 (および内部ノード) は、リアルタイムの計算にはまったく影響しません。なぜ ALTQ がそう考えているのかはわかりません.
<ブロック引用>すべてのリアルタイム曲線の合計が回線速度の 80% を超えてはならないというチュートリアルもあれば、回線速度の 70% を超えてはならないというチュートリアルもあります。どちらが正しいですか、それとも両方とも間違っているのでしょうか?
どちらも間違っています。トラフィックの 70% または 80% に、リアルタイムで指定する必要がある厳しい遅延要件がある場合、実際には、使用しているリンクではほぼ確実にそれらを満たすことができません。より高速なリンクが必要です。
トラフィックの 80% をリアルタイムに指定する必要があると考えられる唯一の方法は、リアルタイムを優先順位のブーストとして踏んでいる場合です。はい、遅延保証を提供するために、実際には一部のパケットの優先度を上げています。ただし、ミリ秒のみにする必要があります。リンクが対処できるのはそれだけであり、それでも遅延保証を提供します。
遅延保証が必要なトラフィックはほとんどありません。 VOIP は 1 つ、NTP は別のものです。残りはすべてリンク共有で行う必要があります。 Web を高速にしたい場合は、ほとんどのリンク容量を Web に割り当てることで高速化します。そのシェアはです 長期にわたって保証されます。 (平均して) レイテンシーを低くしたい場合は、リンク共有の下で凸状の曲線を与えてください。
<ブロック引用>あるチュートリアルでは、すべての理論を忘れなければならないと言いました。物事が実際にどのように機能していても (スケジューラと帯域幅の分配)、次の「単純化されたマインド モデル」による 3 つの曲線を想像してください。リアルタイムは、このクラスが常に取得する保証帯域幅です。リンク共有は、このクラスが必要とする帯域幅です。完全に満足しますが、満足を保証するものではありません。過剰な帯域幅がある場合、満足するために必要な帯域幅よりも多くの帯域幅がクラスに提供されることもありますが、上限が示す以上の帯域幅を使用することはありません。これらすべてが機能するためには、すべてのリアルタイム帯域幅の合計が回線速度の xx% を超えないようにする必要があります (上記の質問を参照してください。パーセンテージはさまざまです)。質問:これは HSFC について多かれ少なかれ正確ですか、それとも完全な誤解ですか?
いい説明上限です。リンク共有の説明は厳密には正確ですが、誤解を招く可能性があります。確かに、リンク共有はリアルタイムのようにハード レイテンシーを保証しませんが、クラスに帯域幅を割り当てるという点で、CBQ や HTB などの競合他社よりも優れています。したがって、リンク共有が「保証を提供しない」と言うのは、他のスケジューラーが提供できるよりも高い基準を維持していることになります。
リアルタイムの説明はどちらも正確ですが、誤解を招くので、間違っていると言えます。名前が示すように、リアルタイムの目的は保証された帯域幅を提供することではありません。これは保証された遅延を提供するためのものです。つまり、リンクの使用方法に応じてランダムな時間が経過するのではなく、パケットがすぐに送信されます。ほとんどのトラフィックでは、遅延の保証は必要ありません。
とはいえ、リアルタイムでも完全なレイテンシーは保証されません。リンクがリンク共有によって管理されていない場合は可能ですが、ほとんどのユーザーは両方を持つという追加の柔軟性を望んでおり、無料では提供されません.リアルタイムは、1 つの MTU パケットを送信するのにかかる時間までに、遅延の期限を逃す可能性があります。 (それが発生した場合、すぐに送信しなければならない短い期限のパケットが与えられた場合に備えて、リアルタイムでリンクをアイドル状態に保ちながら、MTU パケット リンク共有が忍び込んだためです。これは、リンク共有のもう 1 つの違いです。リアルタイムを保証するために、送信するパケットがある場合でも、意図的に回線をアイドル状態に保つことができるため、100% 未満のリンク使用率が提供されます. リンク共有は常に、使用可能なリンク容量の 100% を使用します. リアルタイムとは異なり、それは「仕事の保存」と言えます。）
リアルタイムがハード レイテンシの保証を提供すると言える理由は、遅延が制限されているためです。したがって、1 メガビット/秒のリンクで 20 ミリ秒の遅延保証を提供しようとしていて、リンク共有が MTU サイズ (1500 バイト) のパケットを送信している場合、それらのパケットの 1 つが送信に 12 ミリ秒かかることがわかります。したがって、リアルタイムで 8 ミリ秒の遅延が必要だと伝えた場合でも、20 ミリ秒の期限に間に合わせることができます - 絶対的な保証があります.
<ブロック引用>そして、上記の仮定が本当に正確である場合、そのモデルのどこに優先順位が付けられているのでしょうか?例えば。すべてのクラスには、リアルタイム帯域幅 (保証)、リンク共有帯域幅 (保証されていない)、およびおそらく上限がありますが、それでもクラスによっては、他のクラスよりも優先度の高いニーズがあります。その場合、それらのクラスのリアルタイム トラフィックの中でも、何らかの方法で優先順位を付ける必要があります。曲線の勾配で優先順位を付けますか?もしそうなら、どの曲線ですか？リアルタイムカーブ？リンク共有曲線？上限曲線？それらのすべて？それらすべてに同じ勾配を与えるか、それともそれぞれ異なる勾配を与えるか、正しい勾配を見つける方法は?
優先順位付けモデルはありません。真剣に。トラフィックに絶対優先順位を付けたい場合は、pfifo を使用します。それが目的です。ただし、Web トラフィックを電子メール トラフィックよりも絶対的な優先度に設定すると、Web トラフィックがリンクを飽和させ、電子メール パケットがまったく通過できなくなることにも注意してください。 .その後、すべてのメール接続が切断されます。
実際には、そのような優先順位付けは誰も望んでいません。彼らが望んでいるのは、HFSC が提供するものです。実際にリアルタイムのトラフィックがある場合、HFSC はそれを提供します。しかし、それはすべてのものになります。残りの部分については、HFSC を使用すると、「混雑したリンクでは、90% を Web に割り当て、10% で電子メールを少しずつ送信し、奇妙な DNS パケットをすばやく送信しますが、誰かに DOS で送られないようにしてください」と言うことができます。
解決策 2:
異なる名前で曲線を定義できます:
- rt、リアルタイム曲線、帯域幅/遅延保証。
- ls、リンク共有曲線、帯域幅/遅延共有 (近隣リーフの構成に基づく)
- ul、上限曲線、達成可能な最大帯域幅/遅延
リアルタイム カーブが必要な理由は何ですか? A1、A2、B1、B2 がすべて 128 kbit/s のリンク共有であると仮定すると (どちらにもリアルタイム曲線はありません)、ルートに 512 kbit/s の配信がある場合 (および A と A およびB はもちろん両方とも 256 kbit/s です)、そうですか? A1 と B1 に 128 kbit/s のリアルタイム カーブを追加する必要があるのはなぜですか?これは何に役立ちますか?この 2 つの優先順位を高くするには?元の論文によると、曲線を使用して優先順位を高くすることができます。それが HFSC のすべてです。両方のクラスに [256kbit/s 20ms 128kbit/s] の曲線を与えることで、どちらも自動的に A2 と B2 の 2 倍の優先度を持ちます (まだ平均 128 kbit/s しか得られません)
HFSC でレートのみを定義すると、自動的に 'dmax' が 0 に設定されます。これは基本的に、遅延が考慮されていないことを意味します。適切な HFSC 構成には、クラスに使用する帯域幅と遅延の境界の両方が含まれている必要があります。そうしないと、アルゴリズムは、クラスが取得する優先度を正確に判断できません。
パケットに優先度を与えると、他のパケットの優先度を下げる必要があります。 「dmax」と「rate」の値に基づいて、仮想タイマーを使用してすべてのクラスが多重化されます。詳細については、tc-hfsc(7) を参照してください。
<ブロック引用>リアルタイム帯域幅はリンク共有帯域幅にカウントされますか? A1 と B1 の両方が 64kbit/s のリアルタイムと 64kbit/slink-share 帯域幅しか持っていない場合、リアルタイムで 64kbit/s が提供されると、リンク共有の要件も満たされることを意味しますか?しかし、それは少し無視しましょう) それとも、リンク共有経由で別の 64 kbit/s を取得することを意味しますか?各クラスには、リアルタイムとリンク共有の帯域幅の「要件」がありますか?または、リンク共有曲線がリアルタイム曲線よりも高い場合、クラスの要件はリアルタイム曲線よりも高くなります (現在のリンク共有要件は、指定されたリンク共有要件から、このクラスに既に提供されているリアルタイム帯域幅を差し引いたものに等しい)?
フローがクラスのリンク共有定義の境界を超えていない場合、リアルタイム カーブは使用されません。この場合、リアルタイム曲線を定義すると、たとえば、特定の 'dmax' を保証することができます。
リンク共有の定義に問題がなければ、リアルタイム カーブは必要ありません。サービス カーブ (sc) を定義することもできますが、それでは構成が難しくなります。
<ブロック引用>上限曲線はリアルタイムにも適用されますか、リンク共有のみに適用されますか、それとも両方に適用されますか?一部のチュートリアルでは一方通行で、一部は別の言い方をしています。上限がリアルタイム帯域幅 + リンク共有帯域幅の最大値であると主張する人さえいますか?真実は何ですか?
クラスの上限曲線はリンク共有にのみ適用されます。上限曲線を定義する場合は、リンク共有曲線を定義する必要があります。ただし、親クラスの上限曲線は引き続き適用されます。
<ブロック引用>A2 と B2 が両方とも 128 kbit/s であると仮定すると、A1 と B1 が 128 kbit/s リンク共有のみであるか、または 64 kbit/s リアルタイムで 128 kbit/s リンク共有であるかに違いはありますか?違いは?
わずかな違いがあります。 A2 =0 キロビット/秒、B2 =256 キロビット/秒。その後、A2 の仮想時間は最大になります。パケットが A2 に分類されるたびに、即座に処理されます。ただし、B2 のリアルタイム曲線により、少なくとも 64 kbit/s で送信できることが保証されます
<ブロック引用>別のリアルタイム カーブを使用してクラスの優先順位を上げる場合、なぜ「カーブ」が必要になるのでしょうか?リアルタイムがフラット値でなく、リンク共有もフラット値でないのはなぜですか?なぜ両方が曲線なのですか？クラスごとにその種の属性が 1 つしかないため、元の論文では曲線の必要性は明らかです。しかし今、3 つの属性 (リアルタイム、リンクシェア、上限) を持っているのに、それぞれに曲線が必要なのはなぜでしょうか?曲線の形状 (平均帯域幅ではなく、勾配) をリアルタイムとリンク共有トラフィックで異なるものにする必要があるのはなぜですか?
リアルタイム カーブは隣接リーフ間でトラフィックを共有しませんが、リンク共有カーブは共有します。
<ブロック引用>利用可能なわずかなドキュメントによると、リアルタイムの曲線値は内部クラス (クラス A および B) では完全に無視され、リーフ クラス (A1、A2、B1、B2) にのみ適用されます。それが本当なら、ALTQ HFSC サンプル構成 (3.3 サンプル構成を検索) が内部クラスにリアルタイム曲線を設定し、それらがそれらの内部クラスの保証レートを設定すると主張するのはなぜですか?まったく無意味じゃないですか。 (注:pshare は ALTQ でリンク共有曲線を設定し、リアルタイム曲線を調整します。これは、サンプル構成の上の段落で確認できます)。
内部クラスではリアルタイム カーブが無視され、リーフ クラスにのみ適用されるのは事実です。ただし、これらの内部クラスで定義されたリアルタイム カーブは、リーフ クラスでの計算に考慮されます。
<ブロック引用>すべてのリアルタイム曲線の合計が回線速度の 80% を超えてはならないというチュートリアルもあれば、回線速度の 70% を超えてはならないというチュートリアルもあります。どちらが正しいですか、それとも両方とも間違っているのでしょうか?
つまり、すべてのトラフィックを優先することはできません...パケットに優先順位を付けると、他のパケットの優先順位を下げる必要があります。過大な保証をすると、アルゴリズムは無意味になります。優先されるクラスを定義し、影響を受ける可能性のあるクラスを定義します。
<ブロック引用>あるチュートリアルでは、すべての理論を忘れなければならないと言いました。物事が実際にどのように機能していても (スケジューラと帯域幅の分配)、次の「単純化されたマインド モデル」による 3 つの曲線を想像してください。リアルタイムは、このクラスが常に取得する保証帯域幅です。リンク共有は、このクラスが必要とする帯域幅です。完全に満足しますが、満足を保証するものではありません。過剰な帯域幅がある場合、満足するために必要な帯域幅よりも多くの帯域幅がクラスに提供されることもありますが、上限が示す以上の帯域幅を使用することはありません。これらすべてが機能するためには、すべてのリアルタイム帯域幅の合計が回線速度の xx% を超えないようにする必要があります (上記の質問を参照してください。パーセンテージはさまざまです)。質問:これは HSFC について多かれ少なかれ正確ですか、それとも完全な誤解ですか?
これは正しいです。
<ブロック引用>そして、上記の仮定が本当に正確である場合、そのモデルのどこに優先順位が付けられているのでしょうか?例えば。すべてのクラスには、リアルタイム帯域幅 (保証)、リンク共有帯域幅 (保証されていない)、およびおそらく上限がありますが、それでもクラスによっては、他のクラスよりも優先度の高いニーズがあります。その場合、それらのクラスのリアルタイム トラフィックの中でも、何らかの方法で優先順位を付ける必要があります。曲線の勾配で優先順位を付けますか?もしそうなら、どの曲線ですか？リアルタイムカーブ？リンク共有曲線？上限曲線？それらのすべて？それらすべてに同じ勾配を与えるか、それともそれぞれ異なる勾配を与えるか、正しい勾配を見つける方法は?
の違い。 HFSC と HTB は、HFSC を使用すると、どの程度の優先度を設定するかを正確に定義できるようになるということです。これを行うには、'dmax' 値で最小境界と最大境界を定義します。
解決策 3:
最後に、ほとんどの不一致と、現在の実装が元の論文とどのように異なるかを説明するガイド:
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
このガイドによると、HFSC に関する他の多くのガイドやフォーラムへの投稿はまったくナンセンスです。専門家のように見えて HFSC を完全に理解しているふりをしている多くの人々が、実際には部分的な知識しか持っておらず、概念とそれらすべての設定がどのように連携するかについての誤解に基づいて虚偽の発言をしているため、HFSC がいかに複雑であるかを示しています。
私は最終的にHFSCをあきらめると思います。 HFSC の設定を正しく行うことができれば、最高の QoS が得られる可能性がありますが、完全に失敗する可能性は、成功する可能性よりもはるかに高くなります。