Linux / BSDでのHFSCスケジューリングの仕組みを理解している人はいますか？
私はオリジナルを読みました SIGCOMM '97 PostScript論文 HFSCについて、それは非常に技術的にはですが、基本的な概念を理解しています。他のほとんどすべてのスケジューリングアルゴリズムと同様に、線形のサービスカーブを与える代わりに、凸型または凹型のサービスカーブを指定できるため、帯域幅と遅延を切り離すことができます。ただし、このペーパーでは、使用されているスケジューリングアルゴリズムの種類（リアルタイムおよびリンク共有）について言及していますが、常にスケジューリングクラスごとに1つのカーブしか言及していません（デカップリングはこのカーブを指定することで行われ、そのために必要なカーブは1つだけです） ）。
現在、HFSCは ALTQスケジューリングフレームワーク を使用してBSD（OpenBSD、FreeBSDなど）に実装されており、Linuxは TCスケジューリングフレームワーク （iproute2の一部）を使用して実装されています。 。どちらの実装でも、2つの追加のサービス曲線が追加されました。元の論文では[〜＃〜] [〜＃〜]ではありませんでした！リアルタイムサービス曲線と上限サービス曲線。繰り返しますが、元の論文では2つのスケジューリングアルゴリズム（リアルタイムとリンク共有）について触れていますが、この論文では両方とも1つの単一のサービスカーブで機能します。現在BSDとLinuxで見られるように、どちらか1つに対して2つの独立したサービス曲線はありませんでした。
さらに悪いことに、ALTQの一部のバージョンでは、HSFCにキューの優先順位が追加されているようです（元の論文にも優先順位などはありません）。私はいくつかのBSD HowToがこの優先順位設定について言及していることを発見しました（最新のALTQリリースのmanページはHSFCのそのようなパラメーターを知らないため、公式には存在していません）。
このため、元の論文で説明されているアルゴリズムよりもHFSCのスケジューリングがさらに複雑になり、インターネット上には互いに矛盾するチュートリアルがたくさんあり、一方は他方の反対を主張しています。これがおそらく、HFSCスケジューリングが実際にどのように機能するかをだれも実際に理解していないように見える主な理由です。質問する前に、ある種のサンプル設定が必要です。以下の画像のように、非常にシンプルなものを使用します。
代替テキストhttp://f.imagehost.org/0177/hfsc-test-setup.png
チュートリアルが互いに矛盾しているため、私が答えることができないいくつかの質問があります：
リアルタイムカーブが必要なのはなぜですか？ A1、A2、B1、B2がすべて128 kbit/sのリンク共有であると仮定すると（いずれか1つのリアルタイムカーブはありません）、ルートに512 kbit/sの分散がある場合、これらはそれぞれ128 kbit/sになります（そしてAとBはもちろん256キロビット/秒です）、そうですか？ A1とB1に128 kbit/sのリアルタイムカーブを追加するのはなぜですか？これは何に適していますか？これら2つに高い優先順位を与えるには？元の論文によると、私はcurveを使用してより高い優先順位を与えることができます。それがHFSCの目的です。両方のクラスに[256kbit/s 20ms 128kbit/s]の曲線を与えることにより、どちらも自動的にA2およびB2の2倍の優先度を持ちます（まだ平均で128 kbit/sしか得られません）。
リアルタイム帯域幅はリンクシェア帯域幅にカウントされますか？例えば。 A1とB1の両方に64kbit/sのリアルタイムと64kbit/sのリンク共有帯域幅しかない場合、リアルタイムで64kbit/sが提供されると、リンク共有要件も満たされます（過剰な帯域幅ですが、それを1秒間無視してください）または、リンク共有を介してさらに64 kbit/sを取得するという意味ですか？それでは、各クラスには、リアルタイムとリンク共有の帯域幅「要件」がありますか？または、リンクシェアカーブがリアルタイムカーブよりも高い場合、クラスはリアルタイムカーブよりも高い要件しか持っていません（現在のリンクシェア要件は、指定されたリンクシェア要件からこれにすでに提供されているリアルタイム帯域幅を差し引いたものに等しい）クラス）？
上限曲線はリアルタイムにも適用されますか、リンクシェアのみに適用されますか、または両方に適用されますか？チュートリアルによっては、ある方法で言うものもあれば、別の方法で言うものもあります。リアルタイム帯域幅+リンク共有帯域幅の上限が上限であると主張する人もいますか？真実は何？
A2とB2が両方とも128 kbit/sであると仮定すると、A1とB1が128 kbit/sのリンク共有のみ、または64 kbit/sのリアルタイムと128 kbit/sのリンク共有の場合に違いがありますか。 、何が違うの？
別のリアルタイムカーブを使用してクラスの優先順位を上げると、なぜ「カーブ」が必要になるのですか？なぜリアルタイムのフラットな値とリンクシェアもフラットな値ではないのですか？なぜ両方が曲線なのですか？クラスごとにその種類の属性は1つしかないため、元の論文では曲線の必要性は明らかです。しかし、今、3つの属性（リアルタイム、リンクシェア、上限）があるのに、それぞれに曲線が必要なのはなぜですか？リアルタイム（リンク共有）トラフィックの曲線shape（平均帯域幅ではなく、勾配）を異なるものにしたいのはなぜですか？
入手可能な小さなドキュメントによれば、リアルタイムカーブの値は内部クラス（クラスAおよびB）では完全に無視され、リーフクラス（A1、A2、B1、B2）にのみ適用されます。それが真実である場合、なぜ ALTQ HFSCサンプル構成 （.3サンプル構成を検索）が内部クラスにリアルタイム曲線を設定し、それらが保証されたレートを設定すると主張するのですか？これらの内部クラス？それは完全に無意味ではありませんか？ （注：pshareは、ALTQでリンクシェア曲線を設定し、リアルタイムカーブをすりおろします。これは、サンプル構成の上の段落で確認できます）。
一部のチュートリアルでは、すべてのリアルタイムカーブの合計がラインスピードの80％を超えてはならない、他のチュートリアルではラインスピードの70％を超えてはならない、としています。どちらが正しいですか、それとも両方が間違っているのでしょうか？
あるチュートリアルでは、すべての理論を忘れるように言われました。物事が実際にどのように機能するかに関係なく（スケジューラーと帯域幅の分布）、次の「簡略化されたマインドモデル」に従って3つの曲線を想像してみてください。リアルタイムは、このクラスが常に得る保証された帯域幅です。リンクシェアは、このクラスが完全に満足したい帯域幅ですが、満足を保証することはできません。過剰な帯域幅がある場合、クラスは必要以上に多くの帯域幅を提供される可能性がありますが、上限を超えることはありません。これがすべて機能するためには、すべてのリアルタイム帯域幅の合計が回線速度のxx％を超えるとは限りません（上記の質問を参照してください。割合は変動します）。質問：これは多かれ少なかれ正確であるか、HSFCの完全な誤解ですか？
上記の仮定が本当に正確である場合、そのモデルの優先順位はどこにありますか？例えば。すべてのクラスには、リアルタイム帯域幅（保証）、リンク共有帯域幅（保証なし）、そしておそらく上限があるかもしれませんが、それでも一部のクラスは他のクラスよりも優先度の高いニーズがあります。その場合でも、それらのクラスのリアルタイムトラフィックの間でも、どういうわけか優先順位を付ける必要があります。曲線の傾きを優先しますか？もしそうなら、どの曲線ですか？リアルタイムカーブ？リンクシェア曲線？上限曲線？それらすべて？それらすべてに同じ勾配を与えるか、それぞれに異なる勾配を与え、正しい勾配を見つける方法を教えますか？
この世界には、HFSCを本当に理解し、これらすべての質問に正確に答えることができる人々が少なくとも1人はいるという希望を失っていません。そして、答えを互いに矛盾させることなくそうすることは本当に素晴らしいでしょう;-)
HFSCとそのいとこに関する論文を読むことは、それを理解する良い方法ではありません。 HFSCペーパーの主な目的は、主張の厳密な数学的証明を提供することであり、それがどのように機能するかを説明することではありません。実際、HFSCの論文だけではどのように機能するのか理解できません。参照している論文も読む必要があります。主張や証拠に問題がある場合は、論文の著者に連絡することをお勧めします。そうでなければ、彼らがあなたからの連絡に興味を示すことはないでしょう。
HFSCのチュートリアル を書きました。以下の私の説明が明確でない場合は、読んでください。
リアルタイムカーブが必要なのはなぜですか？ A1、A2、B1、B2がすべて128 kbit/sのリンク共有であると仮定すると（いずれか1つのリアルタイムカーブはありません）、ルートに512 kbit/sの分散がある場合、これらはそれぞれ128 kbit/sになります（そしてAとBはもちろん256キロビット/秒です）、そうですか？ A1とB1に128 kbit/sのリアルタイムカーブを追加するのはなぜですか？これは何に適していますか？これら2つに高い優先順位を与えるには？元の論文によると、カーブを使用することで優先度を高くすることができます。それがHFSCの目的です。両方のクラスに[256kbit/s 20ms 128kbit/s]の曲線を与えることにより、どちらも自動的にA2およびB2の2倍の優先度を持ちます（まだ平均で128 kbit/sしか得られません）。
リアルタイム曲線とリンク共有曲線は、さまざまな方法で評価されます。リアルタイムカーブは、クラスの履歴全体でクラスが行ったことを考慮します。正確な帯域幅と待ち時間の割り当てを提供するために、それを行う必要があります。欠点は、ほとんどの人が直感的にfairと考えるものではありません。リアルタイムでは、クラスが帯域幅を借りて他の誰もそれを望んでいない場合、誰かが後で帯域幅を元に戻したいときにペナルティが課せられます。これは、リアルタイムの保証の下では、誰もそれを望まなかったときに以前に使用したため、クラスが長期間にわたって帯域幅を取得できないことを意味します。
リンク共有は公平であり、予備の帯域幅を使用することでクラスにペナルティを課しません。ただし、これは強力な遅延保証を提供できないことを意味します。
遅延の保証を提供することからリンク共有を分離することは、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が低帯域幅アプリケーションであることを前提としています）。これらすべての最終的な結果は、VOIPパケットの最初のカップルが他よりも速く送信されることを保証し、電子メールの待ち時間が長くなる代わりにVOIPの待ち時間が短くなることです。
先に述べたように、リンク共有は履歴を参照しないため、遅延の保証はできません。確固たる保証は、VOIPのようなリアルタイムトラフィックに必要なものです。ただし、平均してリンク共有の凸曲線は、依然としてトラフィックのレイテンシを向上させます。保証はありません。電子メールを介したWebトラフィックなど、ほとんどの場合それで問題ありません。
入手可能な小さなドキュメントによれば、リアルタイムカーブの値は内部クラス（クラスAおよびB）では完全に無視され、リーフクラス（A1、A2、B1、B2）にのみ適用されます。それが本当である場合、なぜALTQ HFSCサンプル構成（3.3サンプル構成の検索）が内部クラスにリアルタイム曲線を設定し、それらが内部クラスの保証レートを設定すると主張するのですか？それは完全に無意味ではありませんか？ （注：pshareは、ALTQでリンクシェア曲線を設定し、リアルタイムカーブをすりおろします。これは、サンプル構成の上の段落で確認できます）。
ドキュメントは正しいです。階層（したがって内部ノード）は、リアルタイムの計算にはまったく影響しません。 ALTQがどうしてそうしているのか、はっきりとはわかりません。
一部のチュートリアルでは、すべてのリアルタイムカーブの合計がラインスピードの80％を超えてはならない、他のチュートリアルではラインスピードの70％を超えてはならない、としています。どちらが正しいですか、それとも両方が間違っているのでしょうか？
どちらも間違っています。トラフィックの70％または80％に、リアルタイムで指定する必要のあるハードレイテンシの要件がある場合、実際には、使用しているリンクでそれらを満たせないことがほぼ確実です。より高速なリンクが必要です。
誰かがトラフィックの80％をリアルタイムで指定する必要があると考える唯一の方法は、優先度を上げるためにリアルタイムを踏んでいるかどうかです。はい、レイテンシを保証するために、一部のパケットの優先度を実質的に高めています。しかし、それはミリ秒だけであるべきです。これで、リンクが対処でき、レイテンシの保証を提供できます。
レイテンシの保証を必要とするトラフィックはほとんどありません。 NTP別のVOIPです。残りはすべてリンク共有で実行する必要があります。Webを高速にしたい場合は、リンク容量のほとんどを割り当てることで高速にします。その共有is長期にわたって保証されます。（平均で）レイテンシを低くしたい場合は、リンク共有で凸曲線を与えます。
あるチュートリアルでは、すべての理論を忘れるように言われました。物事が実際にどのように機能するかに関係なく（スケジューラーと帯域幅の分布）、次の「簡略化されたマインドモデル」に従って3つの曲線を想像してみてください。リアルタイムは、このクラスが常に得る保証された帯域幅です。リンクシェアは、このクラスが完全に満足したい帯域幅ですが、満足を保証することはできません。過剰な帯域幅がある場合、クラスは必要以上に多くの帯域幅を提供される可能性がありますが、上限を超えることはありません。これがすべて機能するためには、すべてのリアルタイム帯域幅の合計が回線速度のxx％を超えるとは限りません（上記の質問を参照してください。割合は変動します）。質問：これは多かれ少なかれ正確であるか、HSFCの完全な誤解ですか？
良い説明上限です。リンク共有の説明は厳密に正確ですが、誤解を招く可能性があります。それは本当のリンク共有はリアルタイムのようなハードレイテンシの保証を提供しませんが、CBQやHTBなどの競合他社よりもクラスに帯域幅の割り当てを提供するという優れた機能を果たします。したがって、リンクシェアは「保証を提供しない」と言うことで、他のスケジューラが提供できるよりも高い標準にそれを保持しています。
リアルタイムの説明はどちらも正確であるように管理されていますが、誤解を招くので私はそれを間違っていると言います。名前が意味するように、リアルタイムの目的は保証された帯域幅を提供することではありません。それは保証された待ち時間を提供することです-つまり、パケットは今すぐ送信されます。リンクの使用方法に応じて、後でランダムな時間ではありません。ほとんどのトラフィックは保証された待ち時間を必要としません。
とはいえ、リアルタイムでは完全なレイテンシが保証されるわけではありません。リンクがリンク共有によっても管理されていなかったとしても、それは可能ですが、ほとんどのユーザーは両方を持つことのさらなる柔軟性を望んでおり、無料ではありません。リアルタイムでは、1つのMTUパケットを送信するのにかかる時間によって、待ち時間のデッドラインを逃す可能性があります。 （それが発生した場合、すぐに送信する必要のある短い期限のパケットが与えられた場合に備えて、リンクをアイドル状態に保ちながら、リアルタイムでMTUパケットリンク共有が使用されていたことが原因です。これは、リンク共有のもう1つの違いです。とリアルタイム。その保証を提供するために、送信するパケットがある場合でも、リアルタイムで意図的に回線をアイドル状態に保つことができるため、リンク使用率は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のリンク共有であると仮定すると（いずれか1つのリアルタイムカーブはありません）、ルートに512 kbit/sの分散がある場合、これらはそれぞれ128 kbit/sになります（そしてAとBはもちろん256キロビット/秒です）、そうですか？ 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/sのリンク共有帯域幅しかない場合、リアルタイムで64kbit/sが提供されると、リンク共有要件も満たされます（過剰な帯域幅ですが、それを1秒間無視してください）または、リンク共有を介してさらに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かもしれませんが、完全に失敗する可能性は、成功する可能性よりもはるかに高くなります。
元の作者を把握できない場合は、次の方法を試してみます。
- linuxカーネルソースツリーに移動し、「TCスケジューリングフレームワーク」を実装するCファイルを見つけます。
- ヘッダーを見て、コードの作成者を見つけます。
- 「TCスケジューリングフレームワーク」の電子メールプログラマーに、実装に関する文献を求めます。
また、これを引用する他の新しい論文をチェックしてみてください。この分野での研究の続きであり、あなたが尋ねている質問についてのより多くの情報を含むかもしれない新しい論文がそこにあるかもしれません。