ppt

Report
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 シナリオ
–
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
を用いる.
Online software: Online-00-17-02
–
PC
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なし)
●
●
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メッセ−ジの帯域を
確保する.

similar documents