QoS調査研究のまとめ(第２版)

RT99(1999)で発表したこと

• サクレーのデニーたちが行なったATMを用いたイベントビルダ におけるQoSの重要性に着目し、ハードウエアでのQoS機能を持たない イーサネット(ギガビットイーサネットなど)に、ソフトウエアQoSを 適用することで、イベントビルダでソフトウエアQoSを使ったCongestion controlを実現できないか？という提案を行なった。
• QoS技術は幅の広い技術でいろいろあるが、Linuxカーネルに標準に 実装されたQoS技術に焦点を当て、その有効性を調査した。
• ギガビットイーサネット上のTCP/IPにQoSを適用し、 疑似イベントビルダ(1x1システム)で、Assigned rateを与えたと時の measured rateを測定したところ、正しくrate(bandwidth)がassignされて いることがわかった。

DAQ2000(2000)で発表したこと

• 疑似イベントビルダ1x3及び3x1システムで、RT99と同様に測定をした。 その結果、QoSを適用しない場合では1/3に負荷が分散した。 QoSを適用した場合では、assigned rateが小さい時は1/3、 大きくなると3x1システムで多少の乱れ(1/3にならない)が生じた。つまり、 1/3に公平に負荷が分散された訳ではなかった。この結果の評価は、 QoSを適用しない場合負荷が1/3に公平に分散されたのはLinuxがCPUを 各プロセスに公平に与えたからであり、自然である。一方QoSを適用した 場合、多少の乱れがあったものの、rateをアサインできるメリットは 大きい。ROSからのデータフローで、データフローが一様とは限らない。 その場合、各ROSからのData rateをアサインすることで、アンバランスな データフローの各データフローを保証することが可能となる。 以上のことを示した。

CHEP01(2001)で発表したこと

• スケーラビリティーの視点から、Data Flow ManagerからReadOut System へのSubFarm assignementのメッセージはUDP/Multicast技術で行なうことに なっている。これはTCPと違い、一度にメッセージをROSに送ることができる。 しかし、UDPはReliableプロトコルではなく、メッセージのロスを起こす かもしれない。QoSによるtraffic shapping技術で、このパケットロスを 防ぐことはできるだろうか？という点に集中し、調査が行なわれた。
• メッセージをベストエフォートでsenderからreceiverに送った場合、 QoSを適用しない場合は、パケットロスが多発している。しかし、 QoSを適用すると、バケットロスを0%にすることができる。
• CPUの使用率やQoSのオーバーヘッドを測定したが、それは小さかった。
• tcpdumpユーティリティーで調べたところ、QoSのパケットスケジュールが 10msec、つまりLinuxのスケジュールの単位で行なわれていることが わかった。

TDAQweek02で発表したこと

• ATMを用いたEvent builderではConstant Bit Rateを使ったtraffic shaping 技術が有効であったことが証明されている。ATMはハードウエアでQoS技術を 実装しているが、Ethernetはその機能を持っていない。そのため、ソフトウエア QoS技術を使って同様な機能を実現できるかどうかが調査のポイントである。 従って、Linux IP QoSを使って、ランダムに発生するデータを一定の速度 (一定の時間間隔)で送出することができるかどうか調査した。
• すでに10msecのLinuxスケジューリング時間でデータの送出が行われて いることはわかっているが、そのスケジュール間隔を1.5kHz, 4kHzに 変更した場合、どのようになるかUDP/IPを使って調べた。 その結果、ランダムで平均1kHzで到着するイベントフラグメント(データ)が 一定間隔で送出されることを確認した。

最近の調査から

• 最新DataCollectionソフトウエアと最新Onlineソフトウエアを使って、 Nx1, 1xN, MxMのevent builder testbedを構築し、QoSの評価を行っている。
• 大規模testbed
  • ICEPPのtestbed
  • CERNのtestbed

今後の課題

• いままでに確認された重要なポイントは次の３点である。
  • ギガビットイーサネットにQoSを適用した時、Assigned rateを与えたと時の measured rateを測定したところ、正しくrate(bandwidth)がassignされて いることがわかったこと。
  • メッセージをベストエフォートでsenderからreceiverに送った場合、 QoSを適用しない場合は、パケットロスが多発するが、 QoSを適用すると、バケットロスを0%にすることができる。
  • Linuxのスケジュール間隔を1.5kHz, 4kHzに 変更した場合、ランダムで平均1kHzで到着するイベントフラグメント(データ)が 一定間隔で送出されることができる。
• 従って、QoSのイベントビルダへの適用可能性については十分な 証拠を提供したことになるので、実際のevent builder testbedを 使ってQoSを評価することである。
• 評価のポイント
  • QoSは幅広い応用技術であり、単にevent builderのcongestion control のみに適用されるだけでなく、そのtraffic shaping技術を広くデータフロー 及びメッセージフローに適用する可能性について言及すること。
  • 現在はPC上でのLinux QoSを利用しているが、もしevent builder source node(ROB)がPCでなくFPGA ROBのようにハードになったら イーサネットスイッチのQoSも検討する価値がある。
  event builderのcongestion controlがメインテーマだが、 実際にcongestionを引き起こし、congestionによりメッセージが 損失していることを証明するのは簡単ではない。実際起こることは DataCollectionソフトウエアの不備によりメッセージが損失していて それをQoSが救うことができる、ということである。この点は QoSのメリットであり、積極的にQoSを使う理由の１つになりうる。

QoSのメリット

• とにかくオーバーヘッドやCPU使用時間が少なく、 rateを調整できることは素晴らしい。応用範囲は大きい。
• その１つは１つのコンピュータ上にはさまざまなデータフロー／ メッセージフローがあり、そのプライオリティーがある。 それを保証するための技術としてQoSを使う。 例えば、online softwareのメッセージフローとData Collectionの メッセージフロー／データフローのrateをQoSで調整する。 また、アンバランスなデータフローを保証する技術として、 QoSを使う。
• UDPにQoSを適用して確かにパケットロスを防ぐことができる場合が あることはわかった。
• TCP/IPはさまざまなtraffic shaping技術を持っているが、 rateを制限したりする機能は持っていない。たとえ、TCP/IPを使っている 部分でもQoSの適用の意味は無くなる訳ではない。

TDRに向けてやるべきこと

• QoSの調査でやり残した点を整理する。
• TDRに向けて日本の寄与を明確にする。
• QoSの調査で精密測定をすべき点を整理する。