私は原文を読みましたSIGCOMM '97 ポストスクリプト論文HFSC については非常に技術的ですが、基本的な概念は理解しています。線形サービス曲線 (他のほとんどのスケジューリング アルゴリズムと同様) を指定する代わりに、凸型または凹型のサービス曲線を指定できるため、帯域幅と遅延を切り離すことができます。ただし、この論文では使用されているスケジューリング アルゴリズムの種類 (リアルタイムとリンク共有) について言及していますが、常にスケジューリング クラスごとに 1 つの曲線のみについて言及しています (この曲線を指定することによって切り離しが行われ、そのために必要な曲線は 1 つだけです)。
現在HFSCはBSD（OpenBSD、FreeBSDなど）向けに実装されており、ALTQ スケジューリング フレームワークそして、Linuxを使用して実装されていますTC スケジュール フレームワーク（iproute2の一部）。両方の実装では、2つの追加のサービス曲線が追加されました。ない元の論文では、リアルタイム サービス曲線と上限サービス曲線が示されています。元の論文では、2 つのスケジューリング アルゴリズム (リアルタイムとリンク共有) について言及されていますが、その論文では、どちらも 1 つのサービス曲線で動作しています。BSD や Linux で現在見られるような、どちらか一方に 2 つの独立したサービス曲線が存在することはありません。
さらに悪いことに、ALTQ の一部のバージョンでは、HSFC に追加のキュー優先度が追加されているようです (元の論文にも優先度というものは存在しません)。この優先度設定について言及している BSD HowTo をいくつか見つけました (最新の ALTQ リリースのマニュアル ページには HSFC のそのようなパラメータは記載されていないため、公式には存在すらしません)。
このため、HFSC スケジューリングは元の論文で説明されているアルゴリズムよりもさらに複雑になり、インターネット上には互いに矛盾するチュートリアルが山ほどあります。一方が他方と反対のことを主張しています。これがおそらく、HFSC スケジューリングの実際の仕組みを誰も理解していない主な理由でしょう。質問をする前に、何らかのサンプル セットアップが必要です。次の画像に示すような非常にシンプルなものを使用します。
代替テキスト http://f.imagehost.org/0177/hfsc-test-setup.png
チュートリアルが互いに矛盾しているため、回答できない質問がいくつかあります。
リアルタイム曲線は一体何のために必要なのでしょうか? A1、A2、B1、B2 がすべて 128 kbit/s のリンク共有 (いずれにもリアルタイム曲線はありません) であると仮定すると、ルートが 512 kbit/s を分配する場合 (もちろん A と B は両方とも 256 kbit/s)、それぞれに 128 kbit/s が割り当てられますよね? なぜ A1 と B1 に 128 kbit/s のリアルタイム曲線を追加で割り当てるのでしょうか? これは何の役に立つのでしょうか? これら 2 つに高い優先度を与えるためでしょうか? 元の論文によると、曲線結局のところ、それがHFSCのすべてです。両方のクラスに[256kbit/s 20ms 128kbit/s]の曲線を与えることで、両方とも自動的にA2とB2の2倍の優先度を持ちます（それでも平均で128kbit/sしか得られません）
リアルタイム帯域幅はリンク共有帯域幅にカウントされますか? たとえば、A1 と B1 の両方に 64kbit/s のリアルタイム帯域幅と 64kbit/s のリンク共有帯域幅しかない場合、リアルタイムで 64kbit/s が提供されると、リンク共有要件も満たされる (余分な帯域幅が提供される場合もありますが、これは無視します) ということでしょうか、それともリンク共有でさらに 64 kbit/s が提供されるということでしょうか? では、各クラスにはリアルタイムとリンク共有の帯域幅「要件」があるのでしょうか? それとも、リンク共有曲線がリアルタイム曲線よりも高い場合のみ、クラスの要件がリアルタイム曲線よりも高くなるのでしょうか (現在のリンク共有要件は、指定されたリンク共有要件からこのクラスにすでに提供されているリアルタイム帯域幅を引いた値に等しい)?
上限曲線はリアルタイムにも適用されるのでしょうか、それともリンク共有のみに適用されるのでしょうか、それとも両方に適用されるのでしょうか? チュートリアルによっては、一方を述べるものもあれば、反対を述べるものもあります。上限はリアルタイム帯域幅 + リンク共有帯域幅の最大値であると主張する人もいます。真実は何でしょうか?
A2 と B2 が両方とも 128 kbit/s であると仮定した場合、A1 と B1 が 128 kbit/s リンク共有のみの場合、または 64 kbit/s リアルタイムと 128 kbit/s リンク共有の場合、何か違いがありますか。ある場合、どのような違いがありますか。
クラスの優先度を上げるために別のリアルタイム カーブを使用する場合、なぜ「カーブ」が必要なのでしょうか。なぜリアルタイムはフラットな値ではなく、リンク シェアもフラットな値ではないのでしょうか。なぜ両方のカーブがあるのでしょうか。カーブの必要性は元の論文で明らかです。なぜなら、クラスごとにその種の属性が 1 つしかないからです。しかし、3 つの属性 (リアルタイム、リンク シェア、上限) がある場合、それぞれにカーブが必要なのはなぜでしょうか。なぜカーブが必要なのでしょうか。形(平均帯域幅ではなく、その傾斜) は、リアルタイム トラフィックとリンク共有トラフィックで異なるのでしょうか?
入手可能なわずかな資料によると、リアルタイムカーブの値は内部クラス（クラスAとB）では完全に無視され、リーフクラス（A1、A2、B1、B2）にのみ適用されるとのことです。もしそれが本当なら、ALTQ HFSC サンプル構成（検索する3.3 サンプル構成) は、内部クラスにリアルタイム曲線を設定し、それが内部クラスの保証されたレートを設定すると主張しています。これはまったく意味がありませんか? (注: pshare は ALTQ でリンク共有曲線を設定し、リアルタイム曲線をグレーティングします。これは、サンプル構成の上の段落で確認できます)。
一部のチュートリアルでは、すべてのリアルタイム曲線の合計が回線速度の 80% を超えてはならないと記載されていますが、他のチュートリアルでは回線速度の 70% を超えてはならないと記載されています。どちらが正しいのでしょうか。それとも、両方とも間違っているのでしょうか。
あるチュートリアルでは、理論はすべて忘れるべきだと述べられています。物事が実際にどのように機能するか (スケジューラと帯域幅の分配) に関係なく、次の「簡略化されたマインド モデル」に従って 3 つの曲線を想像してください。リアルタイムは、このクラスが常に取得する保証された帯域幅です。リンク共有は、このクラスが完全に満足することを望む帯域幅ですが、満足は保証されません。帯域幅が余っている場合、クラスは満足するために必要な帯域幅よりも多くの帯域幅を提供されることもありますが、上限を超える帯域幅を使用することはありません。これらすべてが機能するには、すべてのリアルタイム帯域幅の合計が回線速度の xx% を超えないようにする必要があります (上記の質問を参照してください。パーセンテージは異なります)。質問: これはほぼ正確ですか、それとも HSFC の完全な誤解ですか?
そして、上記の仮定が本当に正確である場合、そのモデルの優先順位はどこにあるのでしょうか? たとえば、すべてのクラスにリアルタイム帯域幅 (保証)、リンク共有帯域幅 (保証なし)、およびおそらく上限があるかもしれませんが、それでも一部のクラスは他のクラスよりも高い優先度を必要とします。その場合、それらのクラスのリアルタイム トラフィック間でも、何らかの方法で優先順位を付ける必要があります。曲線の傾斜によって優先順位を付けますか? そうであれば、どの曲線ですか? リアルタイム曲線ですか? リンク共有曲線ですか? 上限曲線ですか? すべてですか? すべてに同じ傾斜を与えますか、それともそれぞれ異なる傾斜を与えますか? また、適切な傾斜を見つける方法は?
HFSC を本当に理解し、これらすべての質問に正確に答えられる人がこの世に少なくとも一握りは存在するという希望を私はまだ失っていません。そして、答えが互いに矛盾することなく答えられたら本当に素晴らしいと思います ;-)
答え1
HFSC とその類似の論文を読むことは、HFSC を理解する良い方法ではありません。HFSC 論文の主な目的は、その主張を数学的に厳密に証明することであり、その仕組みを説明することではありません。実際、HFSC 論文だけではその仕組みを理解することはできません。HFSC 論文が参照している論文も読む必要があります。主張やその証明に問題がある場合は、論文の著者に問い合わせるのが良いでしょう。そうでなければ、彼らがあなたの話を聞くことに興味を持つとは思えません。
私はHFSCのチュートリアル以下の説明がわかりにくい場合は読んでみてください。
リアルタイム カーブは一体何のために必要なのでしょうか? A1、A2、B1、B2 がすべて 128 kbit/s のリンク共有 (いずれにもリアルタイム カーブはありません) であると仮定すると、ルートに 512 kbit/s を配布する場合 (もちろん A と B は両方とも 256 kbit/s)、それぞれに 128 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 つが含まれるため)。ただし、リンク共有では履歴パケットが無視されるため、リンク共有を満たす必要があります。
クラスの優先度を上げるために別のリアルタイム曲線を使用する場合、なぜ「曲線」が必要なのでしょうか。なぜリアルタイムはフラットな値ではなく、リンクシェアもフラットな値ではないのでしょうか。なぜ両方の曲線があるのでしょうか。曲線の必要性は元の論文で明らかです。なぜなら、クラスごとにその種類の属性が 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やNTPもその1つです。残りはすべてリンク共有で実現できます。Webを高速化したい場合は、リンク容量の大部分をWebに割り当てて高速化します。その共有は長期的に保証されます。平均的に低遅延にしたい場合は、リンク共有の下に凸曲線を設定します。
あるチュートリアルでは、理論はすべて忘れるべきだと述べられています。物事が実際にどのように機能するか (スケジューラと帯域幅の分配) に関係なく、次の「簡略化されたマインド モデル」に従って 3 つの曲線を想像してください。リアルタイムは、このクラスが常に取得する保証された帯域幅です。リンク共有は、このクラスが完全に満足することを望む帯域幅ですが、満足は保証されません。帯域幅が余っている場合、クラスは満足するために必要な帯域幅よりも多くの帯域幅を提供されることもありますが、上限を超える帯域幅を使用することはありません。これらすべてが機能するには、すべてのリアルタイム帯域幅の合計が回線速度の xx% を超えないようにする必要があります (上記の質問を参照してください。パーセンテージは異なります)。質問: これはほぼ正確ですか、それとも HSFC の完全な誤解ですか?
これは上限の説明としては適切です。リンク共有の説明は厳密には正確ですが、誤解を招く可能性があります。リンク共有はリアルタイムのようにレイテンシを厳密に保証するわけではありませんが、CBQ や HTB などの競合製品よりも、クラスに帯域幅を割り当てる点で優れています。したがって、リンク共有が「保証を提供しない」と言うことは、他のスケジューラが提供できるよりも高い基準を課していることを意味します。
リアルタイムの説明は正確ではありますが、誤解を招く恐れがあるため、間違っていると言えます。名前が示すように、リアルタイムの目的は保証された帯域幅を提供することではありません。保証された遅延を提供することです。つまり、パケットはリンクの使用方法に応じてランダムに一定時間後に送信されるのではなく、今すぐ送信されます。ほとんどのトラフィックでは保証された遅延は必要ありません。
とはいえ、リアルタイムでも完全なレイテンシ保証は得られません。リンクがリンク共有によっても管理されていない場合は保証される可能性がありますが、ほとんどのユーザーは両方を備えた追加の柔軟性を求めており、これは無料では得られません。リアルタイムは、1 つの MTU パケットを送信するのにかかる時間によって、レイテンシ期限を逃す可能性があります。(そのようなことが起こるとしたら、それは MTU パケット リンク共有がこっそりと入り込んでいる一方で、リアルタイムは、すぐに送信しなければならない期限の短いパケットが与えられた場合に備えてリンクをアイドル状態にしておくためです。これは、リンク共有とリアルタイムのもう 1 つの違いです。保証を提供するために、リアルタイムは、送信するパケットがあっても回線を意図的にアイドル状態にして、リンク使用率を 100% 未満に抑える場合があります。リンク共有は常に、リンクの使用可能な容量の 100% を使用します。リアルタイムとは異なり、「作業保存」と言えます。)
リアルタイムが厳格なレイテンシ保証を提供すると言える理由は、遅延が制限されているからです。したがって、1Mbit/秒のリンクで 20ms のレイテンシ保証を提供しようとしており、リンク共有が MTU サイズ (1500 バイト) のパケットを送信している場合、それらのパケットの 1 つを送信するのに 12ms かかることがわかります。したがって、リアルタイムに 8ms のレイテンシを希望すると伝えても、絶対的な保証で 20ms の期限を満たすことができます。
そして、上記の仮定が本当に正確である場合、そのモデルの優先順位はどこにあるのでしょうか? たとえば、すべてのクラスにリアルタイム帯域幅 (保証)、リンク共有帯域幅 (保証なし)、およびおそらく上限があるかもしれませんが、それでも一部のクラスは他のクラスよりも高い優先度を必要とします。その場合、それらのクラスのリアルタイム トラフィック間でも、何らかの方法で優先順位を付ける必要があります。曲線の傾斜によって優先順位を付けますか? そうであれば、どの曲線ですか? リアルタイム曲線ですか? リンク共有曲線ですか? 上限曲線ですか? すべてですか? すべてに同じ傾斜を与えますか、それともそれぞれ異なる傾斜を与えますか? また、適切な傾斜を見つける方法は?
優先順位付けモデルはありません。本当です。トラフィックに絶対的な優先順位を与えたい場合は、pfifo を使用してください。それが pfifo の目的です。ただし、Web トラフィックに電子メール トラフィックよりも絶対的な優先順位を与えると、Web トラフィックがリンクを飽和させ、電子メール パケットが通過しなくなることに注意してください。まったくすべての電子メール接続が切断されます。
実際には、誰もそのような優先順位付けを望んでいません。彼らが望んでいるのは、HFSC が提供するものです。実際にリアルタイム トラフィックがある場合、HFSC はそれを提供します。しかし、それはすべて無駄になります。残りの部分については、HFSC によって、「混雑したリンクでは、Web に 90% を割り当て、電子メールを 10% で流し、たまに DNS パケットをすばやく送信しますが、それによって誰かに DOS 攻撃されないようにする」ということができます。
答え2
異なる名前で曲線を定義することもできます。
- rt、リアルタイム曲線、帯域幅/遅延保証。
- ls、リンク共有曲線、帯域幅/遅延共有（隣接リーフの構成に基づく）
- ul、上限曲線、達成可能な最大帯域幅/遅延。
リアルタイム カーブは一体何のために必要なのでしょうか? A1、A2、B1、B2 がすべて 128 kbit/s のリンク共有 (いずれにもリアルタイム カーブはありません) であると仮定すると、ルートに 512 kbit/s を配布する場合 (もちろん A と B は両方とも 256 kbit/s)、それぞれに 128 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/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」値を使用して最小境界と最大境界を定義することで行います。
答え3
最後に、ほとんどの矛盾点と、現在の実装が元の論文とどのように異なるかを説明しているガイドがあります。
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
このガイドによると、HFSC に関する他の多くのガイドやフォーラムの投稿はまったく意味をなさないということです。これは、HFSC がいかに複雑であるかを示しているだけです。専門家のように見え、HFSC を完全に理解しているふりをしている多くの人々は、実際には部分的な知識しか持たず、概念やすべての設定がどのように連携するかについての誤解に基づいて誤った発言をしています。
ついに HFSC をあきらめようと思います。HFSC を正しく設定できれば、最高の QoS が得られるかもしれませんが、完全に失敗する可能性の方が成功する可能性よりはるかに高くなります。
答え4
元の著者に連絡が取れない場合は、次のことを試してください。
- Linux カーネル ソース ツリーにアクセスし、「TC スケジューリング フレームワーク」を実装する C ファイルを見つけます。
- ヘッダーを見てコードの作成者を見つけます。
- 「TC スケジューリング フレームワーク」のプログラマーに電子メールを送信し、実装に関する資料を要求します。
また、この論文を引用している他の新しい論文も調べてみてください。この分野の研究の継続であり、あなたが尋ねている質問に関するより詳しい情報が含まれている新しい論文があるかもしれません。