4
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 チュートリアルが互いに矛盾しているため、私が答えることができないいくつかの質問があります： リアルタイムカーブが必要なのは何ですか？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しか得られません） リアルタイム帯域幅はリンク共有帯域幅にカウントされますか？たとえば、A1とB1の両方に64kbit / sのリアルタイムと64kbit / sのリンク共有帯域幅しかない場合、リアルタイムで64kbit / sが提供されると、リンク共有要件も満たされることを意味します（余分な帯域幅を取得しますが、それをしばらく無視します）、またはリンク共有を介して別の64 kbit / sを取得することを意味しますか？それで、各クラスには、リアルタイムとリンクシェアの帯域幅の「要件」がありますか？または、リンク共有曲線がリアルタイム曲線よりも高い場合、クラスの要件はリアルタイム曲線よりも高いだけですか（現在のリンク共有要件は、指定されたリンク共有要件からこれに既に提供されているリアルタイム帯域幅を引いたものに等しい）クラス）？ 上限曲線はリアルタイムにも、リンク共有のみに適用されますか、それとも両方に適用されますか？一部のチュートリアルでは、一方の言い方があり、一部は、他の方法で言います。上限がリアルタイム帯域幅+リンク共有帯域幅の最大値であると主張する人もいますか？真実は何？ A2とB2が両方とも128 kbit / sであると仮定すると、A1とB1が128 …