CTA 報告82:

CTA 大口径望遠鏡のデータ収集システム開発
石尾一馬 A、大岡秀行 A、窪秀利 B、今野裕介 B、斎藤浩二 A、齋藤隆之 B、手嶋政廣 A, C、
中嶋大輔 A、花畑義隆 A、林田将明 A、山本常夏 D
東大宇宙線研 A、京大理 B Max-Planck-Inst. fuer Phys. C 甲南大理工 D
2014年 9月 18日
14年9月16日火曜日

日本物理学会 2014年秋季大会@佐賀大学

LST

大口径望遠鏡LSTLST
焦点面に1855本のPMT

直径23m“Dragon” FrontEndBoard
7本のPMTから波形読み出し

×1430 ns

SiTCP技術をFPGA内に実装。
データ送信はTCP/IP通信、その他制御はUDP通信で行われる。

FEB1枚が１回のトリガで送信するデータは{(2 byte/time slice×30time slice) + 1} × (7PMT + 1) × H/L gain = 976Bytes/Event
14年9月16日火曜日

データ転送レートの要求値
PMT
PMT:

PMT

Dragon
FEB
FEB
FEB

×265

PMT×1855(×7 each)

FEB1枚からは、トリガ1回で976Bytes ~ 1KB(8Kbits)
20kHz でトリガがかかる場合、156Mbps
1KB×20kHz = 8Kbits×20kHz =160000kbps=156Mbps

LST1台当たり、156Mbps × 265 FEBs
~40Gbps

LSTは低エネルギーの感度向上に焦点
しかし、低エネルギーほど
background によるトリガレート増加

現行IACT ~0.1kHz
LSTでは、平均20kHzを捌く
データ収集システムが必要(Requirement :15kHz)
14年9月16日火曜日

LST requires
SO TOUGH DAQ SYSTEM

データ収集(DAQ)システムの構成
PMT×1855
PMT
PMT:

PMT

FEB
×265

Switch×6Dragon
FEB
FEB
FEB
×45

CentralControl48port
Ethernet Switch

制御信号
PMT
PMT:

PMT

Dragon
FEB
FEB
FEB
×45::
PMT
PMT:

PMT

48portEthernet Switch::

CameraServerCamera
CameraServer
Server::
観測データ

Dragon
FEB
FEB
FEB
×45

48portEthernet Switch
1Gbps
Ethernet ×45

14年9月16日火曜日

::

監視データ

Each switch transports
156Mbps × 45 ~ 7Gbps

10GbpsSFP+

Data Store
Bulk transport rate
7Gbps × 6 ~ 40Gbps

DAQ Test configuration (Hardware)
Test configuration after FEB is manifactured
Trigger signal・・・

Client(DAQ program)

Data Servers
FEB

FEB
Data

Test configuration before FEB is manifactured
Client(DAQ program)・・・
Data Servers
FakeFEB

FakeFEB
Data

14年9月16日火曜日

TriggerGenerator
TriggerDAQ program “DragonDaq”
DragonDaq
onclient PC

10Gbps SFP+
or1Gbps Ethernet

1Gbps
Ethernet

・データ取得速度に焦点をおいた設計
・1対1direct接続で上限122kHz ~ 905Mbps→ほぼ帯域のリミットを達成（従来のデータ取得プログラムでは上限63kHz）

・複数・任意のIP addressからデータ取得可能
・設定ファイル書換えのみでtarget IP address変更可（再コンパイル不要）
横軸：FEBに与えたトリガの周波数。
縦軸：約108Bytes(105events)を収集した時の換算スループット。
(取得データ量／所要時間)
14年9月16日火曜日

Machine specification
Client PC(Camera server)

部品

型番性能CPUCore i7-4930K
BOX

3.40GHz/ターボブースト時3.90GHz/6-core 12-thread/memoryKS14731821

DiskTranscend
TS256GSSD320

Intel X520DA2

L2 256KBx6/L3 12MB/TDP130W

DDR3 2400MHz CL11 DIMM
2枚により8GB
256GB/SSD/2.5インチ/MLC/SATA 3.0（6Gb/s）Intel X79 Chipset、Intel Core i7対応、SATA3 6.0Gb/s × 8

MotherBoard

X79 Extreme9(Intel X79、Marvell SE9220、Marvell SE9172 によるRAID
0,1,5,10など対応。全てNCQ,AHCI, HotPlug機能) など

Chelsio T420CR

Switch Netgear GS752TXS

14年9月16日火曜日

NIC

Intel
X520DA2

PCI-Express 2.0 対応 5.0 GT/s x 8 Lane

NIC

ChelsioT420CR

PCI-Express 2.0 対応 5.0 GT/s x 8 Lane

intelligent oﬄoad
32K oﬄoaded connections

RJ45 48ポート, 10Gbps SFP+ 4ポート
転送方式：store & forward
システムメモリ：128MB、パケットバッファメモリ：2MB、フラッシュメモリ：32MB
スイッチング・ファブリック：176Gbps、パケットフォワーディング：130.9Mpps
レイテンシ：20μs 以下

NIC比較(DragonDaq／iperfによる計測)
SL65 SFP+
SL65 SFP+

EthUbuntu
on iMacEthIntel
NIC使用

Chelsio
NIC使用

Saturation
Point[kHz]Throughput[Mbps](iMac)

-943

(FEB)

105

785

(iMac)

-944

(FEB)

122

905

NICの転送性能
PC間の通信で同様の性能が出ていてもFEBにおいては、顕著な違い
以降、Chelsio社製NICを用いたSFP+通信でテストを行う。

14年9月16日火曜日

スケールテストで確認すること
本来トリガはランダム(Poisson分布)にかかるが、ネットワークではTCP/IP通信により送信バッファを介して平滑化される。
→近似的に一定間隔のトリガで試験を行う。
FEB側送信バッファ滞留量のシミュレーション結果。
仮定:
40kHzのPoisson分布でトリガがかかりバッファにデータが追加される一方、帯域200Mbps = ~60μs間隔で1460Bytesずつパケット送信される

FEB

トリガによりランダムに976Byteずつ増える

送信により60μs間隔でBuffer

1460Byteずつ減る→20分間データ収集、60μs毎計測の滞留量ヒストグラム

複数FEBからの読み込みも、ネットワークがbusyにならなければ送信バッファを健全に保てる。

スケールテストでsaturationを起こさないか確認
14年9月16日火曜日

Emulator program “FakeFEB” & scale test
Triggersignalip0
Trigger signal

FakeFEB×N・・・

ip1

Trigger
Generator

DragonDaq
Data

ipN
TriggerGenerator

FakeFEB: UDP broadcast packet を送信: Trigger 受信毎に data を送信
FEB

7612345DAQ

120kHz程度まで追随(900Mbps 帯域による制限)

14年9月16日火曜日

スケールテスト結果
11090P

7050
12345678

接続台数(N+1)
書込無書込有(参考)上限スループット[Gbps]

yr
ani
mi
ler

130

スループット／読込回数達成度
100%
5Pre
lim

4ina
ry

3
2
1
080%
60%
40%
20%
0%

1234567

要求値に対する読込回数達成度

上限Trigger Rate[kHz]上限トリガレート8

接続台数(N+1)

45port分のデータを20kHzで捌けるか？
総読込み回数/s（スループット）での比較
Best case : 20kHz × 45 FEBs = 900kHz (6.7Gbps)
Requirement : 15kHz × 45 FEBs = 675kHz (5Gbps)
8台接続で 72kHz×8 = 576kHz (要求値の85%)7台接続で 90kHz×7 = 630kHz (要求値の93%)14年9月16日火曜日

今後の対応策プログラムの書き換え
システムコールを減らす、探索処理をなくす、等

ハードウェア構成・OS設定値見直し
ディスク調整(RAID化)、OS,NIC,Switchの設定調整等

Summary・Dragonからの本格的なデータ収集プログラムを作成した。
1対1接続で従来のデータ確認プログラムの2倍の速さ
複数のFEBから同時読み出し可・Dragonの性能測定帯域の限度に近いレート(905Mbps)でデータが取得できることを確認した。

・Dragon Front End Boardの機能をPC上でEmulateした。
プログラム”FakeFEB”と”TriggerGenerator”を作成
120kHz程度まで追随・スケールテスト
FakeFEBプログラムを作成し、初のスケールテストを行った。
現在のプログラムとハードウェア構成の性能で要求値の85%程度を達成できていることを確認した。
今後、プログラム改善、ハードウェア構成・OS設定の見直しを進めていく。

14年9月16日火曜日