ATLAS実験イベントビルダへの 品質保証機能の適用と性能評価 信州大理，高エ研A，広工大工B，長崎総科大工C，阪大理D 長谷川庸司，安芳次A，真鍋篤A，長坂康史B，下島真C，能町正治D， 藤井啓文A，渡瀬芳行A 日本物理学会 年次大会 2003年3月30日 話の内容 ATLASイベントビルダ 品質保証機能 測定のセットアップ 測定結果 まとめ

ATLAS実験のイベントビルダ(1) Level2 Triggerを満足したイベントに対し，多数の検出器からの データ(Event Fragment) を集めEvent Buildを行う． ROS : Readout System 数100 − 1000ノード DFM : Data Flow Manager SFI : Subfarm Interface 数10ノード Event Build Rateは，1〜3 kHz以上でなければならな い． 1つのROSからSFIに転送さ れるEvent Fragment Sizeの 平均値 ≦ 1kBと予想される ．

ATLAS実験イベントビルダ(2) Push シナリオ Pull シナリオ(要求・応答型) MulticastによりDFMがROSに転 送先のSFIを知らせる． 実装が単純． Traffic Shaping を行わないので ，転送先(SFI)でCongestionが起 こりやすく，結果としてパケッ トロスが起こりやすい． Pull シナリオ(要求・応答型) DFMからSFIにイベントIDが送 られ，それに基づいて，SFIは ROSにデータを要求する． 実装が複雑． Congestionが起こりにくい．

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

イベントビルダへのQoSの導入 Pushシナリオの欠点のCongestionを防ぐために，QoSによりTraffic Shapingを行う． 転送元(ROS)から送出されるデータフローに対しQoSを適用す る． イベントビルダプログラムを変更する必要がない． PushシナリオにQoSを適用し，Congestionが減り，性能が向上するかどうか確かめる．

セットアップ @ CERN DFM, ROS, SFI : Dual Xeon(2.2-2.4GHz) PCs with 1GB RAM, GbE NIC 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 を用いる． PC Online software: Online-00-17-02 GbE スイッチ

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なし) 1×1システムではPushとPullに定性的な差は見られない． 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あり) PushシナリオにQoSを適用 帯域設定 : 20, 40, 50 Mbps 20, 40MbpsではRoB Data Size ≧ 5 kBでEvent Build可能 → Congestionが起こらない． PushのSFIでの最大Throughput: 20Mbps : 18MB/s 40Mbps : 〜40MB/s 50Mbps ではCongestionが起こ る． QoSにより適当な帯域を設定することで，Pushシナリオの場合のCongestionを防ぎ，性能改善が可能である．

まとめ 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メッセ−ジの帯域を 確保する．