DAQ-Middleware Core Meeting

DAQ-MiddlewareCore 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

https://daqmw.kek.jp/redmine/issues/130

産総研 KEK 共同研究延長

2013-03-18 3

２．研究題目次世代高エネルギー加速器データ収集・制御システムに関する研究３．研究目的複数の先端計測・制御機器をネットワーク接続して運用する、データ収集のための計測・制御系の共通の枠組みを提供することで、実験系のニーズに応じたシステム化が容易になるとともに、データ収集やデータ解析の効率化を図る。４．内容及び目標産総研が研究・開発をおこなっているロボット用ミドルウエア技術（ OpenRTM-aist ）や FPGA ハードウエア技術を活用して、次世代高エネルギー加速器実験を効率的に実施出来る先端計測・制御システムのフレームワークを構築する。産総研神徳　徹雄、安藤　慶昭、関山　　守、谷川　民生、小島　一浩、鈴木　良一、大島　永康、原　功

KEK内田、田中、千代

BBT との共同研究（継続）

2013-03-18 4

研究題目DAQ ミドルウェアによる多チャンネル高速データ読出システムの研究開発25 年度は、エラー発生時の動作安定化や原因特定のための機能を強化しつつ、実験に係る周辺デバイスの監視・制御について調査、検討する予定である。BBT: 　和田正樹、間中祐介、渡辺利行KEK: 千代

J-PARC hadron E16

• 2 年後に実験開始• 読み出しシステムの検討• 読み出しソフト今週の予定– SiTCP VME を使って、読み出しテストを行う。– SiTCP VME Master モジュールは J-PARC MLF 中性子 BL 03 (iBIX, 茨城県生物 ) の方からお借りした。– SiTCP VME Master モジュールを読むコードの使用許可もいただいた。

2013-03-18 5

来年度の予定 (1)

• （株） BBT との共同研究は研究代表者が千代にかわり 2012 年度も行うことになりました（ありがとうございます）。和田さんの他に間中さん、渡辺さんが参加されます。• トレーニングコース

KEK 以外での開催 (RCNP で開催できた )• DAQ セミナー (京都大学で開催され、 1日ソフト関連の日で講義を行った )2012-3-15 6

2012-03-15DAQ-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 用 DAQ-

Middleware では xerces-c 2.7 を使っていた ) 。 2.7 → 3.0 でAPI が変わったのでコードを変更する必要がある。

• mod_python, xerces-c 2.7 のままでよいということであれば動くがデプロイ上問題があるか？ (毎日実行されているyum update で xerces-c 2.7 → 3.0 にいつのまにかアップデートされるなど )

2012-3-15 7

DAQ-Middleware 1.2.0 で xerces-3.x対応済。各種 linux distribution対応用枠組みを入れた。



来年度の予定 (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



http://daqmw.kek.jp/docs/daqmw-eng.doc

2013 （平成 25 ）年度行事予定• トレーニングコース– 2013 年 9月上旬広島工業大学• 広工大で講演会（ 1日）＋トレーニングコース１（ DAQ-Middleware 、 2日 ) ＋トレーニングコース 2(FPGA 、 2日 ) の予定

– KEK停電 2013/08/05(月 )～ 07(水 )8/19 の週あたり

–阪大？

2013-03-18 9

2013 08Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 1011 12 13 14 15 16 1718 19 20 21 22 23 2425 26 27 28 29 30 31

2013 09Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 1415 16 17 18 19 20 2122 23 24 25 26 27 2829 30

2013( 平成 25) 年度活動予定• GUI (config.xml 作成、操作パネル ) をソースツリーへ• その他まだソースに反映されていない修正など（ redmine を見よ）• エラー発生時の動作安定化や原因特定のための機能を強化• 制御系準備2013-03-18 10

タイムアウトのバグフィックス(1)

• コンポーネントのデータバッファ– 現在 InPort のみリングバッファを使っている

• バッファの有無は RT のしくみでコンポーネント接続時に指定– タイムアウト付きブロックリード

• 読むデータがなくタイムアウトしたあとは通常どおり一度 daq_run() を終了して、また daq_run() を始める– タイムアウトの指定は DaqOperator がコンポーネント接続時に指定– 現在は 100ms でハードコーディング– 100ms !! ( といえば ) ( 次のスライド )

2013-03-18 11

Source Sink

16384

2816

28

::

601638416384

AB

256kB送る場合

ack のみ

転送速度が突如変動する問題

GIOP Fragment

GIOP reply

GIOP request

2013-03-18 12

DAQ-MiddlewareCore Meeting2012-03-15（１年前）

ズームすると１秒おき１００ミリ秒だけはやくなっている。100 ミリ秒といえばスケジューラ？(2013-03追記 )違いました。タイムアウトを200ms にすると左図で小さくなっている時間が 100ms→200msに連動した

2013-03-18 13


この断層は今回はとりあげません（未解決）（ 2013-03 ）

タイムアウト調査 (1)

• Source から 300ms置きにデータを送ってSink側で InPort の read() にかかる時間を測定

• 100ms のタイムアウトなので連続してread() に 100ms かかるはず

2013-03-18 14

Source Sink


2013-03-18 15


2013-03-18 16

タイムアウト調査 (4)• 絶対時刻で最初の整数秒からの読み取りのみ正常に 100ms かかっている。よく見ると：

2013-03-18 17

0.04+0.06 で 100ms


• InPort read() のタイムアウト設定コードはOpenRTM-aist の src/lib/coil/posix/coil/Condition.h 。1秒以下のタイムアウトはうまく設定されない

2013-03-18 18

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); }


• pthread_cond_timedwait() はタイムアウトを絶対時刻で指定する：

2013-03-18 19

int pthread_cond_timedwait(pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);

pthread_cond_timedwait()RATIONALE

2013-03-18 20

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 exam- ple, assume that clock_gettime() returns the current time and cond_rel- ative_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 irrel- evant 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 oper- ator, it is expected that implementations process any timed wait expir- ing at an intervening time as if that time had actually occurred.


• ミリ秒程度のタイムアウトを許す修正案

2013-03-18 21

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); }


• Source から 350ms 間隔でデータを送る– +50ms はスリープから解除されるのを確認するため

2013-03-18 22

Source Sink


2013-03-18 23

修正案で修正後のテスト。3回 100ms でタイムアウトし、次は50ms まってデータがきたので読んでいる。

Source Sink

16384

2816

28

::

601638416384

AB

256kB送る場合

ack のみ

転送速度が突如変動する問題

GIOP Fragment

GIOP reply

GIOP request

2013-03-18 24


修正前後のリプライ時間差 (1)• 修正前の確認（計算機がかわったので）。前のスライドで Aの時間– ぴょんぴょんはねているのは 50ms 間隔（あとで説明）

2013-03-18 25

Source - Sinktaskset -c 1 Sourcetaskset -c 2,3 SinkSource は一度に 256kB送る100us付近の拡大図は次のスライド

タイムアウト修正前

修正前後のリプライ時間差 (2)

2013-03-18 26

前ページの図、縦軸100us付近の拡大図。Source - Sinktaskset -c 1 Sourcetaskset -c 2,3 SinkSource は一度に 256kB送る

タイムアウト修正前


2013-03-18 27

タイムアウト修正後 Source - Sinktaskset -c 1 Sourcetaskset -c 2,3 SinkSource は一度に 256kB送る100us付近の拡大図は次のスライド


2013-03-18 28

タイムアウト修正後前のスライドの100us付近のズーム。1秒間隔で、 100msだけ小さくなることはなくなった（あるいは 900ms だけ大きくなることはなくなった）。大きさはタイムアウトパッチを当てるまえの 100ms だけの小さいほうのレベル（ 80us ）にあっている。

50ms 間隔とはなにか• とても正確に 50ms 間隔なので、適当に大きくなっているわけではなさそう。• omniORB の設定ファイルのサンプルを見る。

2013-03-18 29

############################################################################# 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

connectionWatchPeriod = 200ms

2013-03-18 30

200ms 間隔になったのでこれであろう。

/etc/omniORB.cfg

InitRef = NameService=corbaname::127.0.0.1:2809supportBootstrapAgent = 1connectionWatchPeriod = 200000 # 200 ms

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

2013-03-18 32

taskset -c 2,3,4 SinkComp

/etc/omniORB.cfg


tasksetせず

2013-03-18 33

taskset で走る CPUコアを指定しないで走らせた場合。/etc/omniORB.cfg


タイムアウトまとめ• src/lib/coil/posix/coil/Condition.h の修正案で十分かどうか確認• connectionWatchPeriod の値を大きくするか検討。

2013-03-18 34

Documents

DAQ-Middleware Core Meeting