Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "ATLAS実験イベントビルダへの 品質保証機能の適用と性能評価"— Presentation transcript:

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

2 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と予想される .

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

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

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

6 CERN DFM, ROS, SFI : Dual Xeon( GHz) PCs with 1GB RAM, GbE NIC GbE Switch : BATM OS : RedHat 7.2 Linux kernel (QoS included) with : Scheduling time HZ = (Hz)→ パケットの 送出時間間隔を細かく 制御(Default = 100). Kernel Buffer size = 8 MB →SFIでのCongestionを 防ぐ. EB software : DC データ転送にはUDP/IP を用いる. PC Online software: Online GbE スイッチ

7 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できなくな る.

8 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に定性的な差は見られない.

9 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で制限

10 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を防ぐことは可能か?

11 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を防ぎ,性能改善が可能である.

12 まとめ 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シナリオ の性能に達するには至らなかった.

13 今後の展望 ATLAS実験で使われるような,より大きなシステムでテス トを行う.→ Scalabilityの確認.
QoSを適用したPushシナリオの性能を,Pullシナリオより改 善することは難しい?. PullシナリオでもQoSを適用して性能が改善するところを考 える. 例えば,control メッセ−ジと dataメッセ−ジを,QoSによ り,別々のクラスに振り分け,controlメッセ−ジの帯域を 確保する.


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

Similar presentations


Ads by Google