Research and Development of Event Building Farm for SuperKEKB

Slides:



Advertisements
Similar presentations
1 広島大学 理学研究科 尾崎 裕介 石川 健一. 1. Graphic Processing Unit (GPU) とは? 2. Nvidia CUDA programming model 3. GPU の高速化 4. QCD with CUDA 5. 結果 6. まとめ 2.
Advertisements

Belle 実験次期 SVD 用読み出しチップを 用いた半導体検出器の検出効率の研究 山中卓研究室 M 1 梶原 俊.
ATLAS実験データ解析に向けた、長距離広帯域ネットワークにおけるデータ転送
Webプロキシサーバにおける 動的資源管理方式の提案と実装
コンピュータプラクティス I 再現性 水野嘉明
高エネルギー加速器研究機構 素粒子原子核研究所 濱田 英太郎
榮樂 英樹 LilyVM と仮想化技術 榮樂 英樹
Report of working at CERN PHOS readout test bench
J-PARC 実験におけるデータ収集環境とシステムデザイン
HLab meeting 7/24/07 K. Shirotori.
COPPER/FINESSE System構築
神奈川大学大学院工学研究科 電気電子情報工学専攻
仮想マシンの並列処理性能に対するCPU割り当ての影響の評価
HTTP proxy サーバにおける 動的コネクション管理方式
東京大学 理学系研究科 物理学専攻 吉原 圭亮 35-096116
相対論的重イオン衝突実験PHENIX におけるシミュレーションによる charm粒子測定の可能性を探る
スーパーカミオカンデに おけるDAQシステム 山田 悟 1, イントロダクション 2, SKオンラインDAQ の構造
大きな仮想マシンの 複数ホストへのマイグレーション
リニアコライダー実験における衝突点回りの測定器の最適化
Tohoku University Kyo Tsukada
LHC Run-2 進展状況 [1] Run-2に向けたアトラス検出器の改良 [0] Run-2 LHC
Ibaraki Univ. Dept of Electrical & Electronic Eng.
MPIによる行列積計算 情報論理工学研究室 渡邉伊織 情報論理工学研究室 渡邉伊織です。
R&D of MPPC including readout electronics
HLab meeting 6/03/08 K. Shirotori.
読み出し回路のアップグレードに向けた研究
MPIを用いた最適な分散処理 情報論理工学研究室 角 仁志
ATLAS実験における 高速トラッキングトリガーシステムの シミュレーションによる最適化
E16実験へのDAQ-Middlewareの応用
ATLAS実験ホールにおける TGC検出器DAQシステムの構築
測定結果(9月) 2005年10月7日.
Vector 4 = [Vector 3, packet_size]
リモートホストの異常を検知するための GPUとの直接通信機構
実行時情報に基づく OSカーネルのコンフィグ最小化
仮想メモリを用いた VMマイグレーションの高速化
複数ホストに分割されたメモリを用いる仮想マシンの監視機構
FPCCDバーテックス検出器における ペアバックグラウンドの評価 4年生発表 2010/03/10 素粒子実験グループ 釜井 大輔.
アトラス実験で期待される物理 (具体例編) ① ② ③ ④ ① ② ③ 発見か? 実験の初日に確認 確認! 2011年5月9日 ④ 未発見
理化学研究所 重イオン核物理研究室 馬場 秀忠
ATLAS実験における高速飛跡トリガーシステムの開発と構築3
LHCでの発見へ向け 世界最大コンピューティンググリッドが始動
ATLAS実験におけるシミュレーションを用いたエンドキャップトリガーの性能評価
SiTCP-VME変換モジュールの開発 KEK 物構研:中性子 佐藤節夫.
ATLAS実験イベントビルダへの 品質保証機能の適用と性能評価
非対称リンクにおける ジャンボフレームの性能評価
3次元位置感応型ガンマ線検出器と それに必要なデバイス
J-PARC E16実験におけるDAQ-Middleware を用いたDAQソフトウェアの開発
宇宙科学統合解析環境の構築とAstro-E2解析支援
未使用メモリに着目した 複数ホストにまたがる 仮想マシンの高速化
ATLAS 実験における Inner Detector を用いた レベル2ミューオン・トリガーの性能評価
複数ホストにまたがって動作する仮想マシンの障害対策
仮想ネットワークを考慮した SoftIRQ制御によるCPU割当ての手法
VMMのソフトウェア若化を考慮した クラスタ性能の比較
B物理ゼミ Particle Detectors:Claus Grupen, Boris Shwartz (Particle id
M. Uchida, Kyoto University
Virtualizing a Multiprocessor Machine on a Network of Computers
ALICE work at CERN Kenta Mizoguchi, Hisayuki Torii, Yusuke Okada
FINESSE 32ch Multi-Hit TDC
広島大学におけるHEPnet-J 利用状況
Mondriaan Memory Protection の調査
ゼロコピー・マイグレーションを 用いた軽量なソフトウェア若化手法
MPIを用いた並列処理計算 情報論理工学研究室 金久 英之
LHC-ATLAS実験開始に向けた ミュー粒子トリガーシステムの統合試運転
ILC衝突点ビームモニターのための 読み出し回路の開発
異種セグメント端末による 分散型仮想LAN構築機構の設計と実装
複数ホストにまたがるVMの 高速かつ柔軟な 部分マイグレーション
ATLAS実験におけるSUSY の発見能力
東大素セ 松本浩,田中純一, 上田郁夫,坂本宏,真下哲郎
ベイジアンネットワークと クラスタリング手法を用いたWeb障害検知システムの開発
Report of working at CERN PHOS readout test bench
Presentation transcript:

Research and Development of Event Building Farm for SuperKEKB Ko Ito Univ. of Tokyo Department of Physics Aihara Group カンペを書く。

Outline Introduction Event building farm for SuperKEKB Performance of Stage1 EB Performance of Stage2 EB Conclusions

Introduction

Belle検出器とDAQのアップグレード Introduction KEKB加速器とBelle実験 世界最高のルミノシティー 1.4x1034cm-2s-1 300fb-1を超えるデータ(3億個のB中間子対に相当) CP violation, rare B decay, τphysics …… b->s penguinにアノマリー 標準模型を超える物理 →SuperKEKB Design luminosity:~5x1035cm-2s-1, 現在の~30倍のluminosity まずKEKB加速器とBelle実験について簡単にお話します。 KEKB加速器は電子陽電子非対称型加速器で、 世界最高のルミノシティー1.4x10^34を達成しています。 Belle実験では現在までKEKB加速器によって生成された 三億個以上のB中間子対を収集しています。 これらの膨大のデータを使用しCP violationやrare B decay、tau physics など様々な物理を研究しています。 また最新の結果ではb->s penguinダイアグラムなどにアノマリーの兆候 が見られるなど標準模型を超える物理の手がかりを掴みつつあります。 そこで我々はさらに多くデータを蓄積するためKEKB加速器のアップグレード を計画しています。 デザインルミノシティーは5x10^35で現在のルミノシティーの30倍の ルミノシティーになります。 KEKB加速器のアップグレードに伴って DAQを含むBelle検出器のアップグレードが必要です。 Belle検出器とDAQのアップグレード

Belle DAQ 生成したB中間子対のほぼ100%をtrigger 7つの検出器からの信号を デジタル化 (約15万チャンネル) 7つの検出器からの信号を デジタル化       (約15万チャンネル) デジタル化されたデータを 一つのeventに構成 不要なバックグラウンド事象をオンラインで除去 オフライン解析のためにeventを記録 つぎに現在のBelle DAQの流れについて説明します。 こちらの絵がBelle検出器の絵で、Belle検出器は7つの検出器から成り立っています。 KEKBによって運ばれた電子陽電子がBelle検出器の中心で衝突し B中間子対を生成します。 生成されたB中間子対は様々な粒子に崩壊します。 Belle検出器はその崩壊を検出します。 DAQとしては生成したB中間子対をほぼ100%triggerします。 そして7つの検出器からのtriggerされた信号をデジタル化します。 現在ではチャンネル数としては約15万チャンネルあります。 そしてデジタル化されたデータを1eventに構成し、 不要なバックグラウンド事象をオンラインで除去し、 オフライン解析のためeventを記録します。 そこで私の研究課題であるEvent Building Farmはこの 「デジタル化したデータを1eventに構成する」 という部分に当たります。

Belle event building farm current EB farm Detector Readout system E1TRK E2TRK E1NEU E2NEU E1VTA E1VTB E2VTX E3 Storage system Trigger Layer1 Laye2 Layer3 RFARM TCP/IPを使ったpoint-to-point接続 Network switchを使用していない 3段階でbuild オンラインでバックグラウンド除去 現在では40kB/event, ~700Hzまで動作可能 次に現在のEB farmについて説明します。 ここに示してあるのがBelle DAQの概略図で、 Detectorからの信号はreadout systemとtrigger systemに 流れ、triggerされデジタイズされたdataはEB farmに入力されます。 そこで現在のEB farmの特徴としましてはfarmを形成しているサーバー達が TCP/IPを使ったpoint-to-point接続によって繋がれており、Network switchを使用して おりません。 そしてreadout systemからのデータは三段階でビルドされストレージされます。 現在のコンフィグレーションは40kB/evt、700Hzまで動作可能なコンフィグレーション となっています。

Requirements for EB Farm Belle SuperKEKB L1 trigger rate 400Hz 10-30kHz Event size@L1 40kB 200-300kB Input nodes 26 >1000 Belle SuperKEKB L1 trigger rate 400Hz Event size@L1 40kB Input nodes 26 1. High trigger rate で動作すること に対応できること 2. Large event size つぎにSuperKEKBのEB farmにたいする要求を述べます。 まずこの表にあるのが現在のBelle EB farmのパラメータに なります。 trigger rateが400Hz、event sizeが40kB、EB farmのinputとしては26inputがあります。 これがSuperKEKBになりますとルミノシティーの増加によって trigger rateは10-30kHzとなり、event sizeは200-300kBにも及びます。 そしてinputの数も1000以上と非常に大きく増えます。 そこでSuperKEKBのためのEB farmは まずHigh trigger rateで動作することが求められ、 Large event size, Large number of input, Luminosity increaseに対応できるという 四点が求められます。 3. Large number of input nodes 4. Gradual luminosity increase

テストシステムを構築しデザインの詳細を決定する Goal of my study SuperKEKBの要求に耐えられる EB farmをデザインする テストシステムを構築しデザインの詳細を決定する そこで本研究の目的としては 「SuperKEKBの要求に耐えられるEB farmをデザインする」 ということと 「そのデザインしたEB farmのテストシステムを構築し その性能を測定しデザインの詳細を決定する」 ということになります。

Event building farm for SuperKEKB つぎにSuperKEKBの為のEB farmについてお話します。

Strategies Multi stageでevent buildingを踏襲 Unit structureを採用 現行のsystemより段数を増加 1000以上のinput nodeから非常に大きいデータサイズの事象を構成 Unit structureを採用 data streamの並列化 現在のEBがunitの1単位 scalableなシステムの構築 2. Large event size 3. Large number of input nodes まず、先程述べた要求に対する我々の開発方針ですが、 まず一点目ですが 「Multi stageでevent buildingを行う」 ということで 現在のsystemより、より多段にevent buildingを行います。 このことは1000以上と考えられるinputから非常に大きいデータサイズの事象を Event buildするための方針で これによって先程あげた四つの内の二つ目と三つ目の要求に対応できます。 次に 「Unit structureを採用」 しました。 これはデータストリームを並列化させPCに対する負荷を分散させます。 unitの単位としては現在のEB farmを一単位とします。 これによって現在のsystemからのupgradeが容易になります。 またscalableなシステムを構築が可能になります。 これによって一つ目と四つ目の要求に対して対応できます。 1. High trigger rate 4. Gradual luminosity increase

Global design of EB farm EB farm for SuperKEKB >1000 inputs 現在のEB farm PC >50 Readout PC Detector 26 inputs Stage1 Stage2 Stage3 Partial Event building Distribution to EB units Full Network Matrix Distribution Readout Networks 先程述べた開発方針に従いましてEB farmをデザインしました。 そのグローバルデザインについてお話します。 こちらに示しますのは現在のEB farmです。 まず大きく変わるところは26のinputが1000以上のinputに変わるところです。 そしてデータストリームを並列化するために現在のEB farmをunitとして配置し、 unitを多数配置します。 1000以上のinputを直接unitに接続するということは現実的でないので inputとunitの間にreadout PCを配置し、event buildingを行います。 こうしますとinputとreadout PCの間にデータを収集するための「Readout Networks」、 readout PCとunitの間にデータ分配するための「Distribution network matrix」が必要となってきます。 Readout networksについてはgigabit network switchを使用し一台のreadout PCによって多数のinputから データを収集します。 Distribution network matrixについてもgigabit network matrixを使用しこのようにnetwork matrixを構築し データを分配します。 このようにnetworkを構成し、detectorからのデータをreadout PCで集め、unitに配りhigh rateに 耐えることが出来ます。 ここでinputからreadout PCの事をstage1、readout PCとunitの間をStage2、unitによるfull event buildingを stage3と定義します。 現行のsystemから大きな変更点はstage1とstsge2を追加したことです。 そこで私はstage1とstage2の開発を行いました。 現行のシステムにStage1とStage2を追加 Stage1とStage2の開発を行った >10 Units

Stage1 (Readout networks) Stage1 Stage2 Stage1についてお話します。

Stage1 - Overview Stage2 1000Base-T EB farmのInput nodeはCOPPER board 100Base-TX Readout PC Stage2 Gigabit network switch 20boards/VME create EB farmのInput nodeはCOPPER board COPPER boardがpipeline読み出しの基本単位 現行DAQのreadoutシステムをCOPPERに置き換え予定 デジタイザーカードとCPUカードをモジュールとして搭載 readout PCにおいてクレート単位のpartial event building stage1はinputとreadout PCの間のnetworkのことです。 ここに示すのがstage1のOverviewです。 今までinputと読んできたものは我々はCOPPER boardと呼ばれるものを想定しています。 COPPER boardは我々が開発しているpipeline読み出しのmoduleです。 こちらの写真がCOPPER boardになります。 COPPER boardにはADC/TDCなどのデジタイザーカードとデータを読み出すCPUカード が搭載されています。またデータを転送する為のnetwork portがon-boardで載っています。 このCOPPER boardは現行のreadout systemに順次置き換わっていく予定です。 stage1ではこのCOPPER boardからクレート単位でgigabit network switchを経由してデータを 読み出しpartial event buildingを行います。

Stage1 - Requirements Stage1 Stage2 一台のreadout PCで最大20COPPER(1クレート)からevent fragmentsを収集 最大30kHzでevent fragmentsを収集し、event buildingを行い、次のstageに転送 Typical trigger rate -- 10kHz Maximum trigger rate -- 30kHz つぎにStage1に対するrequirementですが、 まず一点目としては一台のreadout PCからなるべく多くのCOPPER boardから event fragmentsを収集するということです。 最大で20COPPER boardを想定しています。この値は一つのVMEクレートに相当します。 次に最大30kHzでevent fragmentsを収集し、partial event buildingを行い、次のstageにデータ を転送しなければならない。ということです。 ここで10kHzをtypical trigger rate、30kHzをMaximum trigger rateと定義します。

Stage1 - Parameters Stage1の測定項目 Event rate # of COPPER boards Stage1が処理できる最大のtrigger rate # of COPPER boards 何枚のCOPPER boardからデータを収集できるか つぎにこのStage1のdesignが先程の要求を満たすかどうかを調べる為に 測定しなければならない項目としては次の2点が挙げられます。 まず一点目はevent rateでこれはstage1が処理できる最大のtrigger rateです。 つぎに何枚のCOPPER boardから30kHzでデータを収集するのかを調べる必要があります。 この二点を調べるため…..

テストシステムを構築しStage1の性能を評価。 Stage1 - Setup Stage1 Stage2 テストシステムを構築しStage1の性能を評価。 PC gigabit switch (24port) PC readout PC output PC PC PC PC Event Build PC Readout Networks CPU OS Dual Xeon 3.06GHz With HT RedHat9 kernel2.4.20-8smp PC sender PC (COPPER boardの代わり) 私はテストシステムを構築しstage1の性能を評価しました。 こちらがセットアップの図になります。 COPPER boardの変わりにsender PCと呼ぶPCを20台用意しました。 そしてreadout PCとsender PCの間にsmall gigabit network switchを使用し sender PCとreadout PCをTCP/IPで接続しました。 データの流れは、 まずsender PCがデータを作りそれのデータをswitchを通じてreadout PCに転送します。 そしてreadout PCは受け取ったデータでevent buildを行い、output PCに転送します。  メモリ1GB Small gigabit network switchを使用 sender PCとreadout PCをTCP/IPプロトコルで接続 sender PCとswitchは1000Base-Tで接続(実際は100Base-TX) switchとreadout PCは1000Base-Tで接続

Stage1 - Performance Readout PCで動いている 「event building software」が問題か? event sizeは160Bytes/COPPERを仮定 drift chamberで10%Occupancy # of sender PC : 8 PCs   Event rate : 33.7 kHz Max trigger rateを達成。 # of sender PC : 20 PCs    Event rate : 8.8 kHz Event size = 160Byte sender PCとswitch の間の制限 switchとreadout PC の間の制限 sender PCが増えるにつれ acceptable event rateが低下 30kHz Total transfer rate Total transfer rate: ~40MB/s << gigabit(125MB/s) 10kHz こちらに示すplot1がstage1のperformanceになります。 横軸がsender PCの数、縦軸がEvent rate、kHzです。 event sizeとしては160bytes/COPPERを仮定しています。 この値は現在のBelle drift chamberでの1channelのdata sizeからOccupacy10%を仮定して 算出した値です。 このプロットからsender PCの数が8PCのとき、event rateは33.7kHzでmaximum trigger rateを達成しています。 また想定していた20COPPERでは8.8kHzとtypical trigger rateも達成していません。 またsender PCの数が増加するにつれstage1の処理できるtrigger rateが低下しているのが 分かります。 このプロットにstage1のnetworkからくる制限を加えますとこのようになり 測定したrateはこの制限に影響されているようには見えません。 またswitchとreadout PCの間の転送量を調べますと最大でも40MB/sとnetworkの性能をフルに 使っておらず、networkの性能がevent rateの低下のボトルネックではないということが わかりました。 そこで私はこのevent rateの低下はreadout PCで動いている「event building software」の問題 ではないかと注目しました。 Networkの性能はボトルネックではない Readout PCで動いている 「event building software」が問題か?

Software architecture shared memory Ring Buffer Data flow Linux process TCP socket write PC receiver 1 socket read PC receiver 2 read Next PC socket event build analysis socket PC receiver 3 socket write sender PCの数が20の時 Total processの数は22processes processの数が多すぎて、event build processが十分にCPU timeを使用できていない可能性 PC receiver n socket つぎにevent buildingを行っているsoftwareについて簡単に説明します。 楕円がLinux processで緑の丸がring bufferを形成しているメモリです。 まず送られてきたdataをreceiver processがTCP socketを通じて受け取り それらのdataをevent buildのprocessがevent buildし、こちらのprocessが次のPC buildしたdataを転送します。 ここでsender PCの数が20の時、 totalのprocessの数は22processとなります。 私はこのsoftwareではprocessの数が多すぎてCPU timeが有効に使用できていない可能性が あると考えました。 そこでprocessの数を減らしCPUを有効利用しようと考えました。 全てのStageで使用可能 connectionの数は可変 shared memoryの深さ可変 Processの数を減らす事でCPUを有効利用 する事を試みた

Software modification receiver 2 socket 3 n 1 4 1connection/1process 5connection/1process receiver 1 (select) socket n/5 TCPソケットを複数個を まとめる process数を大幅に 減らすことが可能 どのようにsoftwareを改良したかといいますと 1connectionつき1process立ち上げていたreceiver processをTCP socketを1processに複数個まとめ ました。 こうすることによってprocess数を大幅に減らすことが可能になります。 こちらの図は1processに5つのsocketをまとめた図になります。 数connectionにつき 1process

Stage1 - Performance improvement softwareを改良しsender PCが20台の時、Event rateを測定event sizeは160Byte/COPPER Typical trigger rate 10 kHzを達成 8枚のCOPPERでは30kHzは達成    → Stage1の要求を達成 10枚以上のCOPPER boardから30 kHzで収集するには: softwareの改良 : ring bufferの数を減らす、など PCの速度 : 2倍強速くなれば現行ソフトウェアで可 After1 12 12.1 kHz After1 12 12.1 kHz After2 6 13.4 kHz # = 20 # of process Event Rate Before 22 8.8 kHz そのようにしてsoftwareを改良し、sender PCが20台のとき 再び、event rateを測定しました。 こちらの表がsoftwareを改良するまえの値で、total process数が22で8.8kHzとなっています。 これをまず22processから12processに減らして測定すると12.1kHzと40%程度のimprovementが見られました。 さらにprocessを減らして6processとしますと13.4kHzと50%のimprovementが見られました。 これによってsender PCが20のときtypical trigger rateを達成しました。 また8COPPERのときは30kHzを達成していましたのでこれによってstage1の要求を達成しています。 10枚以上のCOPPER boardから30kHzで収集するには softwareの改良ではevent buildingをはやくするためring bufferの数を減らすなどや PCの速度については2倍強速くなれば現行ソフトウェアで30kHzを達成できるとかんがます。

Stage2 (Distribution network matrix) Stage1 Stage2 次にstage2のstudyについてお話します。

Stage2 - Overview Event 1 Event 2 Readout Networks Event N Stage2 Unit #1 Unit #2 Unit #3 Unit #N-1 Unit #N Readout PC Event 1 Event 2 Readout PC Readout Networks Readout PC Readout PC Event N こちらに示すのがstage2のoverviewになります。 stage1でbuildされたデータをunitに分配するnetwork matrixがstage2になります。 >50 readout PC >10 EB Farm Units Stage2 event fragmentsをEB farm unitsに分配

Stage2 - Requirements Stage1 Stage2 Readout PCがdistribution network matrixを経由してEB farm unitにevent fragmentを分配。 10-30 kHzのhigh rateで動作 ルミノシティーの増加に対応する為、unit structureを採用 unit数の増加に対するscalabilityが必要。 必要とされるunitの数 ~10 units -> EB farm unit event fragments -> fragment

Stage2 - Parameters Stage2の測定項目 Event rate Scalability Stage2が処理できる最大のtrigger rate Scalability unitsの数に対するevent rateの増加

テストシステムを構築しStage2の性能を評価。 Stage2 - Setup Stage1 Stage2 テストシステムを構築しStage2の性能を評価。 distribution network matrix Event 1 PC Build Event 2 PC Event 3 PC Event 4 Event 5 Event 6 Event 7 Event 8 output PC Event 9 説明はぶく。 sender PC (as readout PC) Event 10 gigabit switch (16ports) receiver PC (as unit) CPU OS Dual Xeon 3.06GHz With HT RedHat9 kernel2.4.20-8smp 5x10のdistribution network matrixを構築 small gigabit network switchを使用 ネットワークはすべて1000Base-T

Stage2 - Performance Stage2に対する要求を達成 Event rate Transfer rate Typical event size 3200byte(160bytesx20)の時、47kHz,150MB/sを達成 Event rateもtransfer rateもreceiver PCの数に対してリニア → scalabilityがある どの線を見るのか 線の説明を大きく。 飽和してる理由の説明 Stage2に対する要求を達成

Conclusions

Conclusions このdesign conceptがSuperKEKBでのDAQに対して有効。 SuperKEKBのためのEB Farmをデザインした。 Event Buildingはmulti stageで行う unit structureを採用 Typical event sizeにおいて Stage1(160bytes) event rate 33.7 kHz (8 COPPER boards) event rate 13.4 kHz (20 COPPER boards)を達成 Stage2(3200bytes) event rate 47 kHz (5x10 network matrix) 十分なscalabilityを持つ このdesign conceptがSuperKEKBでのDAQに対して有効。

Backup Backup slide

Introduction – Belle DAQ Readout event building Readout - Q2T and multi hit TDC (gate and delay method)。 Event Building - Switchless event building farm。 Typical trigger rate 400Hzに対してDeadtime2%。 luminosity(1.4x1034)においては非常によく動いている。

Requirements to DAQ Belle SuperKEKB Luminosity(単位) 1.4x1034 5x1035 Physics rate 140Hz 5kHz L1 trigger rate 400Hz 10-30kHz Event size@L1 40kB 200-300kB Data flow rate@L1 20MB/s >2GB/s Data storage rate 10MB/s <250MB/s Reduction factor 2 5-10

System V semaphoreを使い、RingBufferを管理。

Transfer rate per one sender PC Transfer rate of Stage1 Total transfer rate Transfer rate per one sender PC 両方の転送量ともにnetwork performanceをfullに使っていない。 networkがbottleneckになっているわけではない。

Active Process Ratio sender PCの数が増えるにつれratioが下がっている。 event build processがCPUを十分に使っていないのでreceiver processがsleepしてしまう(processが多い)。

Software Modification CPU usageを改良するため、プロセスの数を減らす。 1process,1connectionを1process,数connectionに変更。 e.g. : sender PCが20の時、total processは22プロセス。  改良によって、12,7,6プロセスにできる。

Software modification2 socket socket event build analysis socket socket socket

Software modification2 socket event build analysis socket

multiple TCP socket Multiple TCP socket # of total processes Event rate 1 22 8.8 2 12 12.1 3 7 13.2 4 6 13.4 10 9.5

Multi-Core CPU by Intel

Large-scale network switch CDF – ATM switch (32port) Babar – ATM switch(CiscoLS) CMS – Myrinet(2Gbps), Clos-128port ATLAS – Gigabit (FastIron800/Layer2-3, Batm T6 switch/All-layer) CiscoLS/Catalyst Clos 128port

Scalability event size = 3200 Bytes event size = 6400 Bytes

CPU load of sender PC(800,1600Bytes) receiver PCs sender PCs Distribution network matrix 800Bytes 1600Bytes

# of sender PC = 1 800Byte 1600Byte 3200Byte 6400Byte sender PCが一台の時は、最も速くevent buildingが行われる。 Distribution network matrixのupper limitを知ることができる。 Upper limitが減少。

CPU load of # of sender PC = 1 sender PCのCPU loadは100%になっている。 Upper limit減少は高いCPU loadのせい。

One switch configuration event size = 3200 Byte network switchをnetwork matrixの間に一つだけ配置。 1000Base-Tで飽和が起こっている。 もしevent sizeが6400Byteだったら、 Throughput = 6400Byte x 30kHz = 192 MB/s > 125 MB/s (1000Base-T)

Improvement of Upper limit PC 改良したNetwork matrixを使うことにより、upper limitが改善。

Readout system for SuperKEKB Pipelined readout system Pipeline L1 FIFOを持ったreadout electronics FINESSE Common readout platform (COPPER board) 4 FINESSE, 1 TT-RX, 1 PrPMC module COPPER board

Stage2 - CPU usage event sizeが3200Bytesの時、sender PCのCPU load Readout Networks Network Matrix Distribution CPU loadはunitの数が増えるにつれ増加 理由をちゃんと書く。 Stage1においてevent buildingなどを行うPC 出来る限りstage2にかかるCPU loadを減らしたい CPU loadを減らす為にnetwork matrixを改良

Stage2 - Improvement PC Network switch : 10 --> 3 一台あたり10portを高速で扱うことは CPUに対して高負荷 PC PC portの数を減らす PC PC PC PC Network switch : 10 --> 3 Network port/PC : 10 --> 3 Stage2 (Distribution network matrix)

改良したnetwork matrixでevent rateとCPU loadを測定した。 Stage2 - Improvement Stage1 Stage2 改良したnetwork matrixでevent rateとCPU loadを測定した。 Before After event size 3200Bytes。 Before After CPU load event rate event rate 48kHzを達成し、最大20%程度のCPU load軽減scalabilityも確保 Port数を減らすことは有効、デザインしたnetwork matrixはhigh rateで動作する事を確かめた

Design specification studyを元にdesignの詳細を決定した。 Stage1:16x1のreadout network。 Stage2:Three 8x4のswitchを使用した              distribution network matrix。 Stage1 Stage2

Luminosity upgrade Super-KEKB Crab cavity Lpeak (cm-2s-1) Lint 1.4x1034 280 fb-1 5x1034 1 ab-1 5x1035 10 ab-1 Super-KEKB (major upgrade) Crab cavity

R&D of DAQ system for SuperKEKB SuperKEKBのhigh trigger rate, large event sizeに対して Readout system: 全てパイプライン化する。 (COPPER board)。 Trigger: 現在のシステムを元にシリアル信号でのトリガー伝送。 Storage system: 直接ディスクに 書き込む。 新しいEvent Building Farmの構築が不可欠