ATLAS実験イベントビルダへの品質保証機能の適用と性能評価

信州大理，高エ研 A，広工大工 B，長崎総科大工 C，阪大理 D

長谷川庸司，安芳次 A，真鍋篤 A，長坂康史 B，下島真 C，能町正治 D，藤井啓文 A，渡瀬芳行 A

日本物理学会 年次大会2003年 3月 30日

話の内容

ATLASイベントビルダ品質保証機能測定のセットアップ測定結果まとめ

ATLAS実験のイベントビルダ (1)

● Event Build Rateは， 1〜 3 kHz以上でなければならない．

● 1つの ROSから SFIに転送される Event Fragment Sizeの平均値 ≦ 1kBと予想される．

● Level2 Triggerを満足したイベントに対し，多数の検出器からのデータ (Event Fragment) を集め Event Buildを行う．– ROS : Readout System 数 100 − 1000ノード– DFM : Data Flow Manager– SFI : Subfarm Interface 数 10ノード

ATLAS実験イベントビルダ (2)

● Pull シナリオ (要求・応答型 )– DFMから SFIにイベント IDが送られ，それに基づいて， SFIは ROSにデータを要求する．

– 実装が複雑．– Congestionが起こりにくい．

● Push シナリオ– Multicastにより DFMが ROSに転送先の SFIを知らせる．

– 実装が単純．– Traffic Shaping を行わないので，転送先 (SFI)で Congestionが起こりやすく，結果としてパケットロスが起こりやすい．

品質保証機能 (Quality of Service; QoS)● ネットワークを流れる Data Flowに対し，帯域・エラーレート・遅延の制御を行う．– キューの出口で Schedulerにより Flowが制御される．– 宛先，ポート番号等を基にパケットをクラス分けし，それぞれのキューに振り分ける．

– Estimatorは送出されるパケットを監視しフィードバックをかける．

イベントビルダへの QoSの導入● Pushシナリオの欠点の Congestionを防ぐために， QoSにより

Traffic Shapingを行う．– 転送元 (ROS)から送出されるデータフローに対し QoSを適用する．

● イベントビルダプログラムを変更する必要がない．

Pushシナリオに QoSを適用し， Congestionが減り，性能が向上するかどうか確かめる．

セットアップ @ CERN

● GbE Switch : BATM● OS : RedHat 7.2 Linux kernel

2.4.9-31 (QoS included) with :– Scheduling time HZ = 4096

(Hz)→ パケットの送出時間間隔を細かく制御(Default = 100)．

– Kernel Buffer size = 8 MB →SFIでの Congestionを防ぐ．

● EB software : DC-00-02-02– データ転送には UDP/IPを用いる．

GbE スイッチPC

● DFM, ROS, SFI : Dual Xeon(2.2-2.4GHz) PCs with 1GB RAM, GbE NIC

● Online software: Online-00-17-02

1×1システム (QoSなし )

● ROS × SFI = 1×1， RoB Data Size 1kB (ROSから送出される Event Fragment Size)

● Trigger Rate (Level2 trigger rate)を変えて Event Build Rateを測定．

● 最大レート :– Push: 20 kHz → SFIの CPUで制限

– Pull: 14 kHz → SFIのCPUで制限

● Trigger Rateが 40kHz以上になると， Event Buildできなくなる．

1×1システム (QoSなし )

● ROSから送出される RoB Data Sizeを変えて Event Build Rateと Throughputを測定． Trigger Rage は 25 kHzに固定．

● 最大 Throughput : – Push, Pull : 52 MB/s

@RoB Data Size = 14 kB● RoB Data Size 15 kB ≧ では

Event Buildできなくなる．

1×1システムでは Pushと Pullに定性的な差は見られない．

6×1システム (QoSなし )

● ROS × SFI = 6 × 1， RoB Data Size = 1 kB (ROSから送出される Event Fragment Size)

● Trigger rate (Level2 trigger rate)を変えて Event Build Rateを測定．

● 最大 Event Build Rate:– Push: 5 kHz → SFIの

CPUで制限– Pull: 3.8 kHz → SFIの

CPUで制限

6×1システム (QoSなし )● Pushは RoB Data Size > 5 kBで

EventBuildできなくなる．– SFIで Congestionが発生．

● SFIでの最大 Throughput :– Push : 82MB/s → SFIの

CPUと SFIでの Congestionが制限．

– Pull : 95MB/s → SFIのCPUが制限．

● Pullも RoB Data Size > 14 kBで性能が低下．

Pushシナリオに QoSを適用し， Congestionを防ぐことは可能か ?

6×1システム (QoSあり )

● 20, 40Mbpsでは RoB Data Size 5 kB≧ で Event Build → 可能

Congestionが起こらない．● Pushの SFIでの最大

Throughput:– 20Mbps : 18MB/s– 40Mbps : 〜 40MB/s

● 50Mbps では Congestionが起こる．

QoSにより適当な帯域を設定することで， Pushシナリオの場合の Congestionを防ぎ，性能改善が可能である．

● Pushシナリオに QoS を適用 帯域設定 : 20, 40, 50 Mbps

まとめ● ATLAS DataCollection ソフトウエアに QoS機能を適用し， ROS ×

SFI = 6 × 1のシステムで性能評価を行った．● RoB Data Size(EventFragment Size)が小さく， EventBuildできる条件では， Pushシナリオの方が Pullシナリオより性能が良い．– Pushシナリオ : SFIが動く CPUの負荷が制限．– Pull シナリオ : SFIが動く CPUの負荷が制限．

● Pushシナリオの場合， EventFragment ≧ サイズ 5 kBで EventBuild できなくなる． Pullシナリオではそのようなことが起こらない．– Pushシナリオで Congestionが起こっている．

● Pushシナリオに QoSを適用 : – ≦ 帯域 40Mbps : RoB Data Size 5kB≧ でも EventBuildできる．– ≧ 帯域 50Mbps : QoSなしと変らず Congestionが起こる．– Congestionが起きない範囲で帯域を設定しても， Pullシナリオの性能に達するには至らなかった．

今後の展望● ATLAS実験で使われるような，より大きなシステムでテ

→ ストを行う． Scalabilityの確認．● QoSを適用した Pushシナリオの性能を， Pullシナリオより改善することは難しい ?．

● Pullシナリオでも QoSを適用して性能が改善するところを考える．– 例えば， control − メッセ ジと data −メッセ ジを， QoSにより，別々のクラスに振り分け， control −メッセ ジの帯域を確保する．