Linux / BSDでのHFSCスケジューリングの仕組みを本当に理解している人はいますか？

HFSCに関するオリジナルのSIGCOMM '97 PostScript論文を読みましたが、これは非常に技術的なものですが、基本的な概念は理解しています。ほぼすべての他のスケジューリングアルゴリズムと同様に、線形のサービスカーブを与える代わりに、凸または凹のサービスカーブを指定することができます。したがって、帯域幅と遅延を分離することができます。ただし、このペーパーでは使用されているスケジューリングアルゴリズムの種類（リアルタイムおよびリンク共有）に言及していますが、スケジューリングクラスごとに1つの曲線のみに言及しています（この曲線を指定することで分離が行われ、そのために必要な曲線は1つだけです） ）。

現在、HFSCはALTQスケジューリングフレームワークを使用してBSD（OpenBSD、FreeBSDなど）に実装され、TCスケジューリングフレームワーク（iproute2の一部）を使用してLinuxに実装されています。どちらの実装であった二つの追加サービスカーブ、コメントを追加しないで、元の論文では！リアルタイムのサービス曲線と上限のサービス曲線。繰り返しになりますが、元の論文では2つのスケジューリングアルゴリズム（リアルタイムとリンク共有）に言及していますが、その論文ではどちらも1つのサービスカーブで機能します。現在BSDとLinuxで見られるように、いずれか1つに対して2つの独立したサービス曲線はありませんでした。

さらに悪いことに、ALTQの一部のバージョンは、HSFCにキューの優先順位を追加するようです（元の論文にも優先順位などはありません）。いくつかのBSD HowToがこの優先度設定について言及しているのを見つけました（最新のALTQリリースのマニュアルページはHSFCのそのようなパラメーターを知らないので、公式には存在しません）。

これにより、HFSCのスケジューリングは元の論文で説明されているアルゴリズムよりもさらに複雑になります。また、インターネット上には、しばしば矛盾するチュートリアルがたくさんあります。これがおそらく、HFSCスケジューリングが実際にどのように機能するかを誰も理解していないように見える主な理由です。質問をする前に、何らかのサンプルセットアップが必要です。次の画像に示すように、非常に単純なものを使用します。

代替テキストhttp://f.imagehost.org/0177/hfsc-test-setup.png

チュートリアルが互いに矛盾しているため、私が答えることができないいくつかの質問があります：

1. リアルタイムカーブが必要なのは何ですか？A1、A2、B1、B2がすべて128 kbit / sリンク共有であると仮定すると（どちらもリアルタイムカーブなし）、ルートに配布する512 kbit / sがある場合、それぞれが128 kbit / sを取得します（そしてAとBは両方とももちろん256 kbit / sです）。A1とB1に128 kbit / sのリアルタイムカーブを追加するのはなぜですか？これは何に役立つでしょうか？これら2つに高い優先度を与えるには？元の論文によると、カーブを使用することで優先順位を高くすることができます。両方のクラスに[256kbit / s 20ms 128kbit / s]の曲線を与えると、両方とも自動的にA2とB2の2倍の優先度を持ちます（平均で128 kbit / sしか得られません）

2. リアルタイム帯域幅はリンク共有帯域幅にカウントされますか？たとえば、A1とB1の両方に64kbit / sのリアルタイムと64kbit / sのリンク共有帯域幅しかない場合、リアルタイムで64kbit / sが提供されると、リンク共有要件も満たされることを意味します（余分な帯域幅を取得しますが、それをしばらく無視します）、またはリンク共有を介して別の64 kbit / sを取得することを意味しますか？それで、各クラスには、リアルタイムとリンクシェアの帯域幅の「要件」がありますか？または、リンク共有曲線がリアルタイム曲線よりも高い場合、クラスの要件はリアルタイム曲線よりも高いだけですか（現在のリンク共有要件は、指定されたリンク共有要件からこれに既に提供されているリアルタイム帯域幅を引いたものに等しい）クラス）？

3. 上限曲線はリアルタイムにも、リンク共有のみに適用されますか、それとも両方に適用されますか？一部のチュートリアルでは、一方の言い方があり、一部は、他の方法で言います。上限がリアルタイム帯域幅+リンク共有帯域幅の最大値であると主張する人もいますか？真実は何？

4. A2とB2が両方とも128 kbit / sであると仮定すると、A1とB1が128 kbit / sリンクシェアのみ、または64 kbit / sリアルタイムおよび128 kbit / sリンクシェアである場合に違いはありますか？ 、何の違い？

5. 別のリアルタイムカーブを使用してクラスの優先度を上げると、なぜ「カーブ」が必要なのですか？リアルタイムがフラットな値ではなく、リンクシェアもフラットな値ではないのはなぜですか？なぜ両方の曲線なのですか？元の論文では、クラスごとにその種類の属性が1つしかないため、曲線の必要性は明らかです。しかし、今、3つの属性（リアルタイム、リンク共有、および上限）を持っているので、それぞれの曲線がまだ必要ですか？リアルタイムトラフィックとリンク共有トラフィックで曲線の形状（平均帯域幅ではなく、傾き）を異なるようにしたいのはなぜですか？

6. 利用可能な小さなドキュメントによると、リアルタイムカーブ値は内部クラス（クラスAおよびB）に対して完全に無視され、リーフクラス（A1、A2、B1、B2）にのみ適用されます。それが本当なら、なぜALTQ HFSCサンプル構成（3.3サンプル構成を検索）が内部クラスのリアルタイム曲線を設定し、それらが内部クラスの保証レートを設定すると主張するのですか？それは完全に無意味ではありませんか？（注：pshareは、ALTQでリンク共有曲線を設定し、リアルタイム曲線をグレーティングします。これは、サンプル構成の上の段落で確認できます）。

7. 一部のチュートリアルでは、すべてのリアルタイムカーブの合計が回線速度の80％を超えてはならない、他のチュートリアルでは回線速度の70％を超えてはならないと述べています。どちらが正しいのか、それとも両方とも間違っているのか？

8. あるチュートリアルでは、あなたはすべての理論を忘れなければならないと言いました。物事が実際にどのように機能するか（スケジューラーと帯域幅の分布）に関係なく、次の「単純化されたマインドモデル」による3つの曲線を想像してください。リンクシェアは、このクラスが完全に満足することを望む帯域幅ですが、満足を保証することはできません。過剰な帯域幅がある場合、クラスには必要以上の帯域幅が提供される可能性がありますが、上限よりも多くの帯域幅を使用することはありません。これがすべて機能するためには、すべてのリアルタイム帯域幅の合計が回線速度のxx％を超えない場合があります（上記の質問を参照、割合は異なります）。質問：これは多かれ少なかれ正確ですか、それともHSFCの完全な誤解ですか？

9. また、上記の仮定が本当に正確であれば、そのモデルの優先順位付けはどこにありますか？たとえば、すべてのクラスには、リアルタイム帯域幅（保証）、リンク共有帯域幅（保証なし）、およびおそらく上限がありますが、それでも一部のクラスは他のクラスよりも高い優先度が必要です。その場合、それらのクラスのリアルタイムトラフィックの間でも、何らかの方法で優先順位を付けなければなりません。曲線の勾配で優先順位を付けますか？もしそうなら、どの曲線？リアルタイム曲線？リンクシェア曲線？上限曲線？それらのすべて？それらすべてに同じ勾配を与えるか、それぞれ異なる勾配を与え、正しい勾配を見つける方法を教えてください。

HFSCを本当に理解し、これらすべての質問に正確に答えることができる人がこの世界に少なくとも一杯いるという希望を、私はまだ失っていません。そして、答えで互いに矛盾することなくそうすることは本当に素晴らしいでしょう;-)

HFSCとそのいとこに関する論文を読むことは、それを理解する良い方法ではありません。HFSC論文の主な目標は、その主張の厳密な数学的証明を提供することであり、その仕組みを説明することではありません。実際、HFSCの論文だけではどのように機能するかを理解することはできません。参照する論文も読む必要があります。クレームやその証拠に問題がある場合は、論文の著者に連絡することをお勧めします。

私が書いたHFSCためのチュートリアルを。以下の説明が明確でない場合は読んでください。

リアルタイムカーブが必要なのは何ですか？A1、A2、B1、B2がすべて128 kbit / sリンク共有であると仮定すると（どちらもリアルタイムカーブなし）、ルートに配布する512 kbit / sがある場合、それぞれが128 kbit / sを取得します（そしてAとBは両方とももちろん256 kbit / sです）。A1とB1に128 kbit / sのリアルタイムカーブを追加するのはなぜですか？これは何に役立つでしょうか？これら2つに高い優先度を与えるには？元の論文によれば、私は曲線を使用することで彼らに高い優先順位を与えることができます。両方のクラスに[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リンクシェアである場合に違いはありますか？ 、何の違い？

はい、違いを生みます。リアルタイムを使用する場合、上記で説明したように、レイテンシーは保証されますが、リンクは公平に共有されず（特にクラスが帯域幅不足に陥る可能性があります）、上限は強制されません。リンク共有を使用する場合、遅延は保証されませんが、リンク共有は公平であり、飢ofのリスクはなく、上限が適用されます。リンク共有の前に常にリアルタイムがチェックされますが、これはリンク共有が無視されることを意味するわけではありません。これは、パケットのカウント方法が異なるためです。履歴はリアルタイムで考慮されるため、パケットはリアルタイムの保証を満たす必要はない場合があります（履歴からカウントされるため）が、履歴パケットを無視するためリンク共有を満たすために必要です。

別のリアルタイムカーブを使用してクラスの優先度を上げると、なぜ「カーブ」が必要なのですか？リアルタイムがフラットな値ではなく、リンクシェアもフラットな値ではないのはなぜですか？なぜ両方の曲線なのですか？元の論文では、クラスごとにその種類の属性が1つしかないため、曲線の必要性は明らかです。しかし、今、3つの属性（リアルタイム、リンク共有、および上限）を持っているので、それぞれの曲線がまだ必要ですか？リアルタイムトラフィックとリンク共有トラフィックで曲線の形状（平均帯域幅ではなく、傾き）を異なるようにしたいのはなぜですか？

リアルタイム制御の曲線を使用すると、特定のトラフィッククラス（VOIPなど）の遅延を他のトラフィッククラス（電子メールなど）の遅延と引き換えることができます。リアルタイム制約の下で送信するパケットを決定する際、HFSCは最初に送信を完了するパケットを選択します。ただし、リンクの帯域幅を使用してこれを計算するのではなく、リアルタイムカーブによって割り当てられた帯域幅を使用します。したがって、同じ長さのVOIPおよび電子メールパケットがあり、VOIPパケットに凸曲線があり、電子メールの凹曲線を10倍ブーストすると、最初の電子メールパケットの前に10 VOIPパケットが送信されます。しかし、これはバースト時間でのみ発生します。バースト時間は、せいぜい数パケットを送信するのにかかる時間、つまりミリ秒です。その後、VOIP曲線は平らになるはずです。VOIPは、しばらく停止しない限り、将来のブーストは得られません（VOIPが低帯域幅アプリケーションである場合は、そうする必要があります）。このすべての最終的な結果は、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はもう1つです。残りはすべてリンク共有で行う必要があります。Webを高速にしたい場合は、ほとんどのリンク容量を割り当てて高速化します。そのシェアは長期にわたって保証されています。低遅延（平均）にしたい場合は、リンク共有の下で凸曲線を描きます。

あるチュートリアルでは、あなたはすべての理論を忘れなければならないと言いました。物事が実際にどのように機能するか（スケジューラーと帯域幅の分布）に関係なく、次の「単純化されたマインドモデル」による3つの曲線を想像してください。リンクシェアは、このクラスが完全に満足することを望む帯域幅ですが、満足を保証することはできません。過剰な帯域幅がある場合、クラスには必要以上の帯域幅が提供される可能性がありますが、上限よりも多くの帯域幅を使用することはありません。これがすべて機能するためには、すべてのリアルタイム帯域幅の合計が回線速度のxx％を超えない場合があります（上記の質問を参照、割合は異なります）。質問：これは多かれ少なかれ正確ですか、それともHSFCの完全な誤解ですか？

それは説明の上限です。リンク共有の説明は厳密に正確ですが、誤解を招く恐れがあります。真のリンク共有はリアルタイムのようにハードレイテンシを保証するものではありませんが、CBQやHTBなどの競合他社よりもクラスに帯域幅を割り当てるという優れた仕事をします。そのため、リンク共有は「保証を提供しません」と言って、他のスケジューラが提供できる標準よりも高い標準に保持しています。

リアルタイムの説明は正確に管理されていますが、誤解を招きやすいので間違っています。名前が示すとおり、リアルタイムの目的は保証された帯域幅を提供することではありません。それは保証されたレイテンシーを提供することです-つまり、パケットは今すぐ送信され、リンクの使用方法に応じて後でランダムに送信されるわけではありません。ほとんどのトラフィックは保証されたレイテンシーを必要としません。

とはいえ、リアルタイムでも完全なレイテンシー保証は得られません。リンクがリンク共有によっても管理されていない場合でも可能ですが、ほとんどのユーザーは両方を持つという追加の柔軟性を望んでおり、無料では提供されません。リアルタイムでは、1つのMTUパケットを送信するのにかかる時間までに、遅延の期限を逃す可能性があります。（もしそれが起こるなら、それはそれがすぐに送信されなければならなかった短い期限のパケットを与えられた場合にリンクをアイドル状態に保ちながらリアルタイムでリンクするMTUパケットリンク共有であったためです。これはリンク共有のさらに別の違いですその保証を提供するために、リアルタイムは、送信するパケットがある場合でも、意図的に回線をアイドル状態に保つため、100％未満のリンク使用率が提供されます。リンク共有は常にリンクの使用可能な容量の100％を使用します。 、

リアルタイムがハードレイテンシ保証を提供すると言える理由は、遅延が制限されているためです。したがって、1Mビット/秒のリンクで20msの遅延保証を提供しようとしており、リンク共有がMTUサイズ（1500バイト）のパケットを送信している場合、それらのパケットの1つが送信に12msかかることがわかります。したがって、8ミリ秒の遅延が必要な場合は、絶対保証で20ミリ秒の期限を守ることができます。

また、上記の仮定が本当に正確であれば、そのモデルの優先順位付けはどこにありますか？たとえば、すべてのクラスには、リアルタイム帯域幅（保証）、リンク共有帯域幅（保証なし）、およびおそらく上限がありますが、それでも一部のクラスは他のクラスよりも高い優先度が必要です。その場合、それらのクラスのリアルタイムトラフィックの間でも、何らかの方法で優先順位を付けなければなりません。曲線の勾配で優先順位を付けますか？もしそうなら、どの曲線？リアルタイム曲線？リンクシェア曲線？上限曲線？それらのすべて？それらすべてに同じ勾配を与えるか、それぞれ異なる勾配を与え、正しい勾配を見つける方法を教えてください。

優先順位付けモデルはありません。真剣に。トラフィックに絶対優先順位を付けたい場合は、pfifoを使用します。それが目的です。ただし、Webトラフィックに電子メールトラフィックよりも絶対的な優先順位を与えると、Webトラフィックがリンクを飽和させ、電子メールパケットがまったく通らなくなることに注意してください。その後、すべてのメール接続が停止します。

現実には、誰もそのような優先順位付けを望んでいません。彼らが望むのは、HFSCが提供するものです。実際にリアルタイムのトラフィックがある場合、HFSCはそれを提供します。しかし、それはすべてのものになります。残りについては、HFSCでは「混雑したリンク上で90％をWebに割り当て、10％で電子メールを細流化し、奇数のDNSパケットをすばやく送信しますが、だれかがそれをDOSにしないでください」と言うことができます。

異なる名前で曲線を定義できます。

• rt、リアルタイム曲線、帯域幅/遅延保証。
• ls、リンク共有曲線、帯域幅/遅延共有（ネイバーリーフの構成に基づく）
• ul、上限曲線、到達可能な最大帯域幅/遅延。

リアルタイムカーブが必要なのは何ですか？A1、A2、B1、B2がすべて128 kbit / sリンク共有であると仮定すると（どちらもリアルタイムカーブなし）、ルートに配布する512 kbit / sがある場合、それぞれが128 kbit / sを取得します（そしてAとBは両方とももちろん256 kbit / sです）。A1とB1に128 kbit / sのリアルタイムカーブを追加するのはなぜですか？これは何に役立つでしょうか？これら2つに高い優先度を与えるには？元の論文によれば、私は曲線を使用することで彼らに高い優先順位を与えることができます。両方のクラスに[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 / sのリンク共有帯域幅しかない場合、リアルタイムで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 kbits / sとB2 = 256 kbits / sの場合、わずかな違いがあります。その後、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」値で最小および最大境界を定義します。

最後に、ほとんどの矛盾と、現在の実装が元の論文とどのように異なるかを説明しているように見えるガイド：

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

このガイドによると、HFSCに関する他の多くのガイドおよびフォーラム投稿はまったくナンセンスです。専門家のように見えてHFSCを完全に理解しているふりをする多くの人々が実際に部分的な知識しか持っておらず、概念の誤解とそれらのすべての設定がどのように連携しているかに基づいて虚偽の陳述をしているため、HFSCがどれほど複雑であるかを示しているだけです。

私はついにHFSCをあきらめると思います。HFSCのセットアップを正しく行うことができれば、最高のQoSを得ることができますが、完全に混乱する可能性は、成功する可能性よりもはるかに高くなります。

元の著者を把握できない場合は、次にこれを試してみます。

1. Linuxカーネルソースツリーに移動して、「TCスケジューリングフレームワーク」を実装するCファイルを見つけます。
2. ヘッダーを見て、コードの作成者を見つけます。
3. 「TCスケジューリングフレームワーク」の電子メールプログラマーに、実装に関する文献を求めます。

また、この論文を引用している他の新しい論文もチェックしてみてください。この分野での研究の継続であり、あなたが尋ねている質問についてのより多くの情報を含むかもしれないより新しい論文があるかもしれません。