Transcript ppt

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