Difference: Dec2016TestbeamLog (22 vs. 23)

Revision 232016-12-16 - AtlasjSilicon

Line: 1 to 1

META TOPICPARENT	name="FermilabTestbeam"

Dec2016 FNAL Test Beam Log

Line: 233 to 233

beam status

TLU

SVX

Added:

>
>

SEABAS2とSCTJDAQ PCとのTCP connection errorの原因調査を行なった。
[現在の環境]
8ポートのうち、PATCH PANEL;SCTJDAQ PC;KEKSiPC;RaspberryPiが接続されている。
2本は先に何も繋がっていない、テスト用ポート。
[構成1]
SEABAS2をSw-Hubに、SCTJDAQ PCもSw-Hubに接続した。
この時のSw-Hubはビームホール内の物(阪大から持参)である。LANケーブルの長さは2本とも7m程度のものである。
SVXのデータはSCTJDAQ PCの外付けハードディスクに保存され、これをKEKSiPCから見られるようにNFSクライアントを立ち上げて参照できるようにしている。
そのため、SEABAS2とSCTJDAQの2接続が必要になるのでSCTJDAQ PCから2本のLANケーブルを伸ばしている。なお、ethernetポートが1つしかないので、SEABAS2にはLANポートを、共有NetworkにはUSB Ethernet Adapterで接続している。
[結果1]
上の状況では、SCTJADAQ PCとSEABAS2のTCP connectionの確立までに10秒程度時間がかかる。
11:20にDAQをstartしたが、その3分後イベントが増えなくなる。TCP connectionが途切れる。この時約42000eventsほど。
[構成2]
共有Networkに接続せず、Sw-Hubのみ経由でSCTJDAQ PCとSEABAS2を接続する。
[結果2]
TCP connectionは意外にもあっさり通った。
11:24にDAQをstartした。1分後TCP connectionが途切れた。
[結論]
Sw-Hub経由でSCTJDAQ PCとSEABAS2との通信を行うと、通信が不安定になることがある。
[考察]
Sw-Hubを介すると通信が不安定になるのはなぜか？
一つ考えられるのはrootingの不具合。他のDAQによる通信が同じSw-Hubを経由して行われていることも考えられるか。
また、SOIグループではSEABAS2をSw-Hub経由でDAQ PCと通信しているが、このような通信の不安定性は見られないという。
ファームウェアの問題かもしれないが、これは調査に知識と時間がかかる。
何が問題かはもう一度阪大で精査する必要がある。
[回避策]
SEABAS2とSCTJDAQ PCは直接イーサネットケーブルで接続するようにする。

12/16

12/17

12/18

View topic | History: r36 < r35 < r34 < r33 | More topic actions...