アカウント名:
パスワード:
速度差が存在するネットワークで発生する問題だと言うのもポインとだと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
queue アルゴリズム (スコア:5, 参考になる)
Internet (パケットネットワーク)の仕組としてバースト時のパケットロスをなくすためにキューにバッファリングする仕組みがある。バンド幅の向上に合わせてこのキューもどんどん大きくなって来ているが、単にそれだけではなく、パケットロスは少なければ少ないほど良いと勘違いしたものか、大は小を兼ると思い込んだのか無闇やたらバッファーがでかくなる症状が流行っている。
ところがキューを大きくすると確かにパケットロスは減るが、大きくすればするほどパケットの遅延が酷いことになる。パケット遅延は別にリアルタイムゲーム等でのみで必要な要素ではなく、混雑時のデータ転送速度に大きな影響を与える。単に帯域幅が広いだけじゃ駄目なのである。
特にTCP通信においては致命的。TCP通信には輻輳回避機構があってパケットロスを検知して、最適な通信速度を探す仕組みがあるのだが、パケット遅延が大きくなるとこの仕組みがうまく働くなる。具体的にはネットワークが混雑していてもキューで処理している期間はパケットロスが発見できないため輻輳の検知が遅れ、必要なタイミングからかなり遅れて送信制限がかかることになる。その時点ではもはや間に合わず通信が完全停止するくらいまで減速されてしまう。そして通信を再開するがその時にはキューが空いているので全力で送信してしまい輻輳させてしまう。車に例えるならばアクセル全開と急ブレーキを交互に踏んでいるような状態であり、実際の帯域幅を有効に使えない。
この問題は古くから知られているが、あんまり対策が進んでいない。対策としてキューの管理をもっと賢くする AQM (Active Queue Management)というものがある。
比較対象として普通のキューの Tail Dropping 方式をまず説明する。この方式は単純にキューがいっぱいになったら、それ以後の新たなパケットを破棄するという方式である。Linux をはじめとする各OSやルーターやスイッチのキューもデフォルトではこの方式である。この方式はキューが大きくなるとディレイが長くなる。キューに滞留している時間はパケットロスを検知できないという欠陥がある。
AQM の代表的な例として RED (Random Early Detection/Dropping) 方式がある。この方式はキューの埋まり具合に応じて、キューが一杯になる前にランダムにパケットのドロップし始める。キューが一杯になる前に輻輳が検知できるためにTCPの輻輳検知が有効に働く。Linux や Cisco や Juniper のルーター等にはこの設定ができる。この方式の欠点としてドロップ率等のパラメータを手作業できちんとチューニングしてやらなければならい点がある。落とし過ぎると帯域が埋まる前に輻輳制御してしまうし、落とし方が足りないと結局キューに溜って遅延が長くなる。このような性質のため帯域幅が動的に変化するような環境で使用するのが困難であり、そもそも設定が面倒なので固定幅に帯域制限しているような場合以外ではあまり使われていない。
そして今回話題に上がっているのは新しい AQM 方式の CoDelである。この方式はざっくり説明すると、パケットがキューに滞在している時間を調べて長時間キューに滞在しているパケットは片っ端からドロップするやり方。時間がパラメータになっているので帯域幅が変動してもパラメータは同じで良いし、パケットのキュー滞在時間は変化しないのでキューも大きくならず輻輳検知にも影響しない。細かい調整無しで使えるのでデフォルトの Tail Dropping 方式を置きかえてることができるはず。
# Linux 3.5 ってどんだけ先なんだと一瞬思ったけど手元のマシンが Linux 3.4 だった。順当に行けば来月くらいかな。
# でも、この方式がルーターに実装されて各ISP等に配備されるには5年単位の時間がかかりそうだ。
Re:queue アルゴリズム (スコア:2)
Re: (スコア:0)
速度差が存在するネットワークで発生する問題だと言うのもポインとだと思う。