Difference: Dec2016TestbeamLog (23 vs. 24)

Revision 242016-12-16 - AtlasjSilicon

Line: 1 to 1

META TOPICPARENT	name="FermilabTestbeam"

Dec2016 FNAL Test Beam Log

Line: 215 to 215

SVX

OnlineMonitor 用にバイナリデータのデコーダを書いている。設計方針はfixされた。
確認のために書いておくと、EventNumber, Timestamp, hit ch X, hit ch Y, adc, pipelineIDのデータを出力して、他の検出器とのCorrelationを同時に見られるようにすること。
class SVXconverter {
private:
string filename;
ifstream infile;
int xx;
int EventNumber;

public:
SVXconverter(string filename);
~SVXconverter();

void GetAnEvent (int &eventnum, int *xx);
void GetEvent (int EventNumber);
void GetNextEvent ();
};
のようなテンプレートクラスに沿って設計。現在のTreeConveterとは異なるが、getterはひとまず実装済み。
イベントナンバーを指定してイベント情報をgetできるようなメソッドを実装する。これが結構難しいというか面倒な部分。

Changed:

<
<

[Remained Task]

>
>

[Remain Task]

LANケーブルの長さ？によるTCP connectionエラーの再現性のチェック
死んだNo.2 SVX Telescopeの原因調査
解析プログラムTestBeamAnaの改良。

Line: 233 to 233

beam status

TLU

SVX

Changed:

<
<

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は直接イーサネットケーブルで接続するようにする。

>
>

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の不具合。なぜおこるのかはハブの仕様を知らないとわからない。
また、SOIグループではSEABAS2をSw-Hub経由でDAQ PCと通信しているが、このような通信の不安定性は見られないという。
ファームウェアの問題という可能性もあるが、これは調査に知識と時間がかかる。
何が問題かはもう一度阪大で精査する必要がある。
[問題の回避策]
SEABAS2とSCTJDAQ PCは直接イーサネットケーブルで接続するようにする。
OnlineMonitor の開発
SCTJDAQで出力されるバイナリファイルのデコーダを開発中。EventNumberを引数にすればそのイベントの情報を出力するメソッドは実装したがデバッグがまだ必要。
telescopeごとにhitchとadcの値を出力するが、全部同じになってしまっているバグ。早く直す。
今のところバイナリデータを前からreadしながらストリームの位置をシークしているが、イベントヘッダからイベントデータサイズ(byte単位)のみ取得してその分だけストリームの位置をシークするようなコードの方がスマートな気がするので、動作速度に問題、余裕があればその方針でも考えて見る。
SVXconverter.hh(未修正版)

[Remain Task]
- 死んだNo.2 SVX Telescopeの原因調査
- 解析プログラムTestBeamAnaの改良。

12/16

12/17

12/18

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