DAQ-Middleware
Core Meeting
千代浩司
大学共同利用機関法人
高エネルギー加速器研究機構
2013-03-18
1
もくじ
• 報告
– 産総研 KEK 共同研究 延長
– BBTとの共同研究（継続）
– J-PARC hadron E16 (High Pt)
– 2012(平成24)年度活動予定と結果（2012-12-14
に報告済み、再掲）
– 2013年度計画
– タイムアウトにまつわるバグフィックス
redmine: https://daqmw.kek.jp/redmine/issues/130
2013-03-18
2
産総研 KEK 共同研究 延長
２．研究題目
次世代高エネルギー加速器データ収集・制御システムに関する研究
３．研究目的
複数の先端計測・制御機器をネットワーク接続して運用する、データ収集のため
の計測・制御系の共通の枠組みを提供することで、実験系のニーズに応じたシス
テム化が容易になるとともに、データ収集やデータ解析の効率化を図る。
４．内容及び目標
産総研が研究・開発をおこなっているロボット用ミドルウエア技術（OpenRTM-aist）
やFPGAハードウエア技術を活用して、次世代高エネルギー加速器実験を効率的
に実施出来る先端計測・制御システムのフレームワークを構築する。
産総研
神徳 徹雄、安藤 慶昭、関山
KEK
内田、田中、千代
2013-03-18
守、谷川 民生、小島 一浩、鈴木 良一、大島 永康、原 功
3
BBTとの共同研究（継続）
研究題目
DAQミドルウェアによる多チャンネル高速データ読出システムの研究開発
25年度は、エラー発生時の動作安定化や原因特定のための機能を強化しつつ、
実験に係る周辺デバイスの監視・制御について調査、検討する予定である。
BBT: 和田正樹、間中祐介、渡辺利行
KEK: 千代
2013-03-18
4
J-PARC hadron E16
• 2年後に実験開始
• 読み出しシステムの検討
• 読み出しソフト 今週の予定
– SiTCP VMEを使って、読み出しテストを行う。
– SiTCP VME MasterモジュールはJ-PARC MLF中性
子 BL 03 (iBIX, 茨城県生物)の方からお借りした。
– SiTCP VME Masterモジュールを読むコードの使用
許可もいただいた。
2013-03-18
5
2012-03-15
DAQ-Middleware
Core Meeting
(赤文字は今回追加し
たもの)
来年度の予定 (1)
• （株）BBTとの共同研究は研究代表者が千代
にかわり2012年度も行うことになりました（あ
りがとうございます）。和田さんの他に間中さ
ん、渡辺さんが参加されます。
• トレーニングコース
KEK以外での開催 (RCNPで開催できた)
• DAQセミナー (京都大学で開催され、1日ソフ
ト関連の日で講義を行った)
2012-3-15
6
2012-03-15
DAQ-Middleware
Core Meeting
(赤文字は今回追加し
たもの)
来年度の予定 (2)
• Scientific Linux 6.2への対応
– すでに判明している改修しなければならない点
SL 6.2に入っているもので
• mod_python → mod_wsgi の変更 (パッケージ名として
mod_pythonも使えるが中身はmod_wsgi)
• xerces-c 3.0が含まれるようになった（SL 5.x用DAQMiddlewareでは xerces-c 2.7を使っていた)。2.7 → 3.0でAPI
が変わったのでコードを変更する必要がある。
• mod_python, xerces-c 2.7のままでよいということであれば
動くがデプロイ上問題があるか？ (毎日実行されている
yum updateでxerces-c 2.7 → 3.0 にいつのまにかアップデー
トされるなど)
DAQ-Middleware 1.2.0で xerces-3.x対応済。各種linux distribution対応用枠組み
を入れた。
2012-3-15
7
2012-03-15
DAQ-Middleware
Core Meeting
(赤文字は今回追加し
たもの)
•
来年度の予定 (3)
Debian, Ubuntu系への対応
– debパッケージの作成とネットワーク経由セットアップスクリプトの作成 (井上さんの作業。報
告)
•
GUI
– WebUI以外のパネル (安さん作のものができた。一部問題あり。回避案あり。)
– config.xml作成GUI (仲吉さん作成のものをベースに拡張する)
(配布物にまだ入れていない。仲吉さん作のもので問題はない)
•
DAQ-Middleware自体のテストシステム
– 昨年DaqOpeartorのメモリーリーク等があったのでリリース前にリグレッションが無いかテスト
することができれば便利かと思う。
(手つかず)
•
ホームページ改装
– 日本語と英語
(ホームページは未対応。「開発マニュアル」英訳は会社に発注した。2013年1月末に納品。
品質はかなりよい模様。
http://daqmw.kek.jp/docs/daqmw-eng.doc
に置いてある)
2012-3-15
8
2013（平成25）年度行事予定
• トレーニングコース
– 2013年9月上旬 広島工業大学
• 広工大で講演会（1日）＋トレーニングコース１（DAQMiddleware、2日) ＋ トレーニングコース2(FPGA、2日)
2013 08
の予定
Su Mo Tu We Th
1
4 5 6 7 8
11 12 13 14 15
18 19 20 21 22
25 26 27 28 29
Fr
2
9
16
23
30
Sa
3
10
17
24
31
– KEK停電 2013/08/05(月)～07(水)
8/19の週あたり
2013 09
– 阪大？
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
2013-03-18
9
2013(平成25)年度活動予定
• GUI (config.xml作成、操作パネル)をソースツ
リーへ
• その他まだソースに反映されていない修正な
ど（redmineを見よ）
• エラー発生時の動作安定化や原因特定のた
めの機能を強化
• 制御系準備
2013-03-18
10
タイムアウトのバグフィックス(1)
• コンポーネントのデータバッファ
– 現在InPortのみリングバッファを使っている
• バッファの有無はRTのしくみでコンポーネント接続時に指定
– タイムアウト付きブロックリード
• 読むデータがなくタイムアウトしたあとは通常どおり一度
daq_run()を終了して、またdaq_run()を始める
– タイムアウトの指定はDaqOperatorがコンポーネント
接続時に指定
– 現在は100msでハードコーディング
– 100ms !! (といえば) (次のスライド)
2013-03-18
11
DAQ-Middleware
Core Meeting
2012-03-15
（１年前）
転送速度が突如変動する問題
Source
256kB送る場合
16384
Sink
:
:
28
GIOP Fragment 16
ackのみ
GIOP reply
28
A
B
GIOP request 60
16384
16384
2013-03-18
12
DAQ-Middleware
Core Meeting
2012-03-15
（１年前）
この断層は今回は
とりあげません（未
解決）（2013-03）
ズームすると１秒おき１
００ミリ秒だけはやく
なっている。
100ミリ秒といえばスケ
ジューラ？
(2013-03追記)
違いました。
タイムアウトを200msに
すると左図で小さくなっ
ている時間が
100ms→200msに連動
した
2013-03-18
13
タイムアウト調査 (1)
Source
Sink
• Sourceから300ms置きにデータを送ってSink
側でInPortのread()にかかる時間を測定
• 100msのタイムアウトなので連続してread()に
100msかかるはず
2013-03-18
14
タイムアウト調査 (2)
2013-03-18
15
タイムアウト調査 (3)
2013-03-18
16
タイムアウト調査 (4)
• 絶対時刻で最初の整数秒からの読み取りの
み正常に100msかかっている。よく見ると：
0.04+0.06で100ms
2013-03-18
17
タイムアウト調査 (5)
• InPort read()のタイムアウト設定コードは
OpenRTM-aistの
src/lib/coil/posix/coil/Condition.h 。
1秒以下のタイムアウトはうまく設定されない
bool wait(long second, long nano_second = 0)
{
timespec abstime;
abstime.tv_sec = std::time(0) + second;
abstime.tv_nsec = nano_second;
return 0 == ::pthread_cond_timedwait(&m_cond, &m_mutex.mutex_, &abstime);
}
2013-03-18
18
タイムアウト調査 (6)
• pthread_cond_timedwait()はタイムアウトを絶
対時刻で指定する：
int pthread_cond_timedwait(pthread_cond_t *restrict cond,
pthread_mutex_t *restrict mutex,
const struct timespec *restrict abstime);
2013-03-18
19
pthread_cond_timedwait()
RATIONALE
man 3p pthread_cond_timedwait
Timed Wait Semantics
An absolute time measure was chosen for specifying the timeout parameter for two reasons. First, a relative time measure can be easily
implemented on top of a function that specifies absolute time, but
there is a race condition associated with specifying an absolute timeout on top of a function that specifies relative timeouts. For example, assume that clock_gettime() returns the current time and cond_relative_timed_wait() uses relative timeouts:
clock_gettime(CLOCK_REALTIME, &now)
reltime = sleep_til_this_absolute_time -now;
cond_relative_timed_wait(c, m, &reltime);
If the thread is preempted between the first statement and the last
statement, the thread blocks for too long. Blocking, however, is irrelevant if an absolute timeout is used. An absolute timeout also need not
be recomputed if it is used multiple times in a loop, such as that
enclosing a condition wait.
For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred.
2013-03-18
20
タイムアウト調査 (7)
• ミリ秒程度のタイムアウトを許す修正案
bool wait(long second, long nano_second = 0)
{
struct timeval tv;
timespec abstime;
::gettimeofday(&tv, NULL);
abstime.tv_sec = tv.tv_sec + second;
abstime.tv_nsec = tv.tv_usec*1000 + nano_second;
if (abstime.tv_nsec >= 1000000000) {
abstime.tv_nsec -= 1000000000;
abstime.tv_sec ++;
}
return 0 == ::pthread_cond_timedwait(&m_cond, &m_mutex.mutex_, &abstime);
}
2013-03-18
21
タイムアウト調査 (8)
Source
Sink
• Sourceから350ms間隔でデータを送る
– +50msはスリープから解除されるのを確認するため
2013-03-18
22
タイムアウト調査 (9)
修正案で修正後の
テスト。
3回100msでタイム
アウトし、次は50ms
まってデータがきた
ので読んでいる。
2013-03-18
23
DAQ-Middleware
Core Meeting
2012-03-15
（１年前）
転送速度が突如変動する問題
Source
256kB送る場合
16384
Sink
:
:
28
GIOP Fragment 16
ackのみ
GIOP reply
28
A
B
GIOP request 60
16384
16384
2013-03-18
24
修正前後のリプライ時間差 (1)
• 修正前の確認（計算機がかわったので）。前のスライドでAの時間
– ぴょんぴょんはねているのは50ms間隔（あとで説明）
タイムアウト
修正前
2013-03-18
Source - Sink
taskset -c 1 Source
taskset -c 2,3 Sink
Sourceは一度に256kB送
る
100us付近の拡大図は次
のスライド
25
修正前後のリプライ時間差 (2)
タイムアウト
修正前
2013-03-18
前ページの図、縦軸
100us付近の拡大図。
Source - Sink
taskset -c 1 Source
taskset -c 2,3 Sink
Sourceは一度に256kB送
る
26
修正前後のリプライ時間差 (3)
タイムアウト
修正後
2013-03-18
Source - Sink
taskset -c 1 Source
taskset -c 2,3 Sink
Sourceは一度に256kB送
る
100us付近の拡大図は次
のスライド
27
修正前後のリプライ時間差 (4)
タイムアウト
修正後
2013-03-18
前のスライドの100us
付近のズーム。
1秒間隔で、100msだ
け小さくなることはなく
なった（あるいは
900msだけ大きくなる
ことはなくなった）。
大きさはタイムアウト
パッチを当てるまえの
100msだけの小さい
ほうのレベル（80us）
にあっている。
28
50ms間隔とはなにか
• とても正確に50ms間隔なので、適当に大きく
なっているわけではなさそう。
• omniORBの設定ファイルのサンプルを見る。
############################################################################
# connectionWatchPeriod
#
# For each endpoint, the ORB allocates a thread to watch for new
# connections and to monitor existing connections for calls that
# should be handed by the thread pool. The thread blocks in select()
# or similar for a period, after which it re-scans the lists of
# connections it should watch. This parameter is specified in
# microseconds.
#
# Valid values = (n >= 0 in microseconds)
#
connectionWatchPeriod = 50000
2013-03-18
29
connectionWatchPeriod = 200ms
/etc/omniORB.cfg
InitRef = NameService=corbaname::127.0.0.1:2809
supportBootstrapAgent = 1
connectionWatchPeriod = 200000 # 200 ms
200ms間隔になったので
これであろう。
2013-03-18
30
taskset -c 2,3 for SinkComp
• taskset: そのプロセス（あるいはそこから発生するス
レッド）が動作するCPUコアを指定するコマンド。
• いままのでテストでは
– CPU #1にSourceComp
– CPU #2, #3にSinkComp
– (註)DAQ-Middleware配布物にはこのようにセットしている
ところはない。
• ラン中にCPUコアが移動し、L2キャッシュの効き具合が
かわるのを防ぐためにtasksetして計測していた
• SinkCompはメインスレッドとInPortスレッドでCPUを1個
以上消費することがあるので2個指定している。
2013-03-18
31
taskset -c 2,3,4 for SinkComp
taskset -c 2,3,4 SinkComp
/etc/omniORB.cfg
InitRef = NameService=corbaname::127.0.0.1:2809
supportBootstrapAgent = 1
connectionWatchPeriod = 200000 # 200 ms
2013-03-18
32
tasksetせず
tasksetで走るCPUコア
を指定しないで走ら
せた場合。
/etc/omniORB.cfg
InitRef = NameService=corbaname::127.0.0.1:2809
supportBootstrapAgent = 1
connectionWatchPeriod = 200000 # 200 ms
2013-03-18
33
タイムアウトまとめ
• src/lib/coil/posix/coil/Condition.hの修正案で
十分かどうか確認
• connectionWatchPeriodの値を大きくするか検
討。
2013-03-18
34
© Copyright 2024 ExpyDoc
