Difference:
Dec2016TestbeamLog
(22 vs. 23)
Revision 23
2016-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
|
H
istory
:
r36
<
r35
<
r34
<
r33
|
More topic actions...
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback