DAQ-Middleware Core Meeting

1. DAQ-MiddlewareCore Meeting 千代浩司 大学共同利用機関法人 高エネルギー加速器研究機構

2. もくじ • 報告 • 産総研 KEK 共同研究 延長 • BBTとの共同研究（継続） • J-PARC hadron E16 (High Pt) • 2012(平成24)年度活動予定と結果（2012-12-14に報告済み、再掲） • 2013年度計画 • タイムアウトにまつわるバグフィックス redmine: https://daqmw.kek.jp/redmine/issues/130

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

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

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

6. 2012-03-15 DAQ-Middleware Core Meeting (赤文字は今回追加したもの) 来年度の予定 (1) • （株）BBTとの共同研究は研究代表者が千代にかわり2012年度も行うことになりました（ありがとうございます）。和田さんの他に間中さん、渡辺さんが参加されます。 • トレーニングコース KEK以外での開催 (RCNPで開催できた) • DAQセミナー (京都大学で開催され、1日ソフト関連の日で講義を行った)

7. 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用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 にいつのまにかアップデートされるなど) DAQ-Middleware 1.2.0で xerces-3.x対応済。各種linux distribution対応用枠組み を入れた。

8. 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 に置いてある)

9. 2013（平成25）年度行事予定 • トレーニングコース • 2013年9月上旬 広島工業大学 • 広工大で講演会（1日）＋トレーニングコース１（DAQ-Middleware、2日) ＋ トレーニングコース2(FPGA、2日) の予定 • KEK停電 2013/08/05(月)～07(水) 8/19の週あたり • 阪大？ 2013 08 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 31 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

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

11. タイムアウトのバグフィックス(1) • コンポーネントのデータバッファ • 現在InPortのみリングバッファを使っている • バッファの有無はRTのしくみでコンポーネント接続時に指定 • タイムアウト付きブロックリード • 読むデータがなくタイムアウトしたあとは通常どおり一度daq_run()を終了して、またdaq_run()を始める • タイムアウトの指定はDaqOperatorがコンポーネント接続時に指定 • 現在は100msでハードコーディング • 100ms!! (といえば)(次のスライド)

12. DAQ-Middleware Core Meeting 2012-03-15 （１年前） 転送速度が突如変動する問題 Source Sink 256kB送る場合 16384 : : 28 GIOP Fragment 16 ackのみ A GIOP reply 28 B GIOP request 60 16384 16384

13. DAQ-Middleware Core Meeting 2012-03-15 （１年前） ズームすると１秒おき１００ミリ秒だけはやくなっている。 100ミリ秒といえばスケジューラ？ (2013-03追記) 違いました。 タイムアウトを200msにすると左図で小さくなっている時間が100ms→200msに連動した この断層は今回はとりあげません（未解決）（2013-03）

14. タイムアウト調査 (1) Source Sink • Sourceから300ms置きにデータを送ってSink側でInPortのread()にかかる時間を測定 • 100msのタイムアウトなので連続してread()に100msかかるはず

15. タイムアウト調査 (2)

16. タイムアウト調査 (3)

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

18. タイムアウト調査 (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); }

19. タイムアウト調査 (6) • pthread_cond_timedwait()はタイムアウトを絶対時刻で指定する： int pthread_cond_timedwait(pthread_cond_t *restrict cond, pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);

20. pthread_cond_timedwait()RATIONALE man 3p pthread_cond_timedwait Timed Wait Semantics An absolute time measure was chosen for specifying the timeout parame- ter 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 time- out 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.

21. タイムアウト調査 (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); }

22. タイムアウト調査 (8) Source Sink • Sourceから350ms間隔でデータを送る • +50msはスリープから解除されるのを確認するため

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

24. DAQ-Middleware Core Meeting 2012-03-15 （１年前） 転送速度が突如変動する問題 Source Sink 256kB送る場合 16384 : : 28 GIOP Fragment 16 ackのみ A GIOP reply 28 B GIOP request 60 16384 16384

25. 修正前後のリプライ時間差 (1) • 修正前の確認（計算機がかわったので）。前のスライドでAの時間 • ぴょんぴょんはねているのは50ms間隔（あとで説明） Source - Sink taskset -c 1 Source taskset -c 2,3 Sink Sourceは一度に256kB送る 100us付近の拡大図は次のスライド タイムアウト修正前

26. 修正前後のリプライ時間差 (2) 前ページの図、縦軸100us付近の拡大図。 Source - Sink taskset -c 1 Source taskset -c 2,3 Sink Sourceは一度に256kB送る タイムアウト修正前

27. 修正前後のリプライ時間差 (3) タイムアウト修正後 Source - Sink taskset -c 1 Source taskset -c 2,3 Sink Sourceは一度に256kB送る 100us付近の拡大図は次のスライド

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

29. 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

30. connectionWatchPeriod = 200ms /etc/omniORB.cfg InitRef = NameService=corbaname::127.0.0.1:2809 supportBootstrapAgent = 1 connectionWatchPeriod = 200000 # 200 ms 200ms間隔になったのでこれであろう。

31. 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個指定している。

32. 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

33. tasksetせず tasksetで走るCPUコアを指定しないで走らせた場合。 /etc/omniORB.cfg InitRef = NameService=corbaname::127.0.0.1:2809 supportBootstrapAgent = 1 connectionWatchPeriod = 200000 # 200 ms

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