KiNOKO-DAQ 関連情報 掲示板

このスレッドに記事を投稿する
前のスレッド | 次のスレッド | 掲示版ホーム

kcomスクリプト
2007 年 8 月 27 日 21 時 38 分
投稿者: 平野

お世話になっております。

ADC×4、東洋テクニカcc7700、smallkinokoを用いてデータをとっているのですが、もっとデットタイムを減らすことができないかと考えています。現在、トリガー レイトは約1100 cpsで、実際にとっているのは、約200cps です。たとえば二つのパソコンを用いて、Collectorを一つのパソコンに、その他Recorder,Viewer等をもう一つのパソコンに割り当てたら、もっと早くデータをとることができると期待してもよいのでしょうか。もちろんパソコンの性能等にも依ると思いますが、これについて何かアドバイスをいただけたらと思っています。

実は、実際に試してみようかと思い、その前にkcomスクリプトの理解を深めるため
src/kernel/lib-common/kcom/samples のサンプルと、SmallKinoko.kcomを読み、実際の動作を確認しようとして、
(コマンド) kinoko sample.kcom としたのですが、

KCOM_PATH: .:/usr/local/kinoko/bin
KORB_PROJECT_PATH: /usr/local/kinoko
launching controller: StartStop@localhost (control is 'display: localhost:0.0')
launching message_board: MessageBoard@localhost (control is 'display: localhost:0.0')
launching fibonacci: Fibonacci@localhost (control is 'display: localhost:0.0')
/usr/bin/xterm Xt error: Can't open display: localhost:0.0
/usr/bin/xterm Xt error: Can't open display: localhost:0.0
/usr/bin/xterm Xt error: Can't open display: localhost:0.0
3 components are not attached. still waiting...
3 components are not attached. still waiting...
・・・
となり、このまま
3 components are not attached. still waiting...
がつづき、うまく動きません。この場合は何が原因なのでしょうか。

どうぞよろしくお願い致します。


無題
2007 年 8 月 30 日 8 時 37 分
投稿者: 榎本三四郎

kcom/samples にある sample.kcom が動作するには、
% xterm -display localhost:0.0
がうまく動作する必要があるのですが、最近のセキュリティが
強化された Linux ではデフォルトでは動作しないように
なっているようです。
"display: localhost:0.0" の代わりに、"port: 10000""
などにして、xterm をあらかじめ開いておいてそこから
% telnet localhost 10000
とすれば、とりあえずは動作すると思います。

Collectorコンポーネントだけを別PCに移す SmallKinoko.kcom を作成したので、添付しておきます。
先頭付近にある daq_host を適当に指定すれば、そこに Collector が配置されます。ただし、あらかじめ daq_host で指定されるPCに Kinoko が同じ状態でインストールされていて、
かつ、ssh daqhost がパスワードなしで行えるようになっている必要があります(ssh-agent などをうまく活用してください).

ご指摘のとおり、Collector を別PCにしても、それにより性能が上がるかは状況によります。ネットワークが速く、CPUとディスクがあまり速くないような状況では効果がありますが、ネットワークが遅いか、ネットワーク転送にCPUが消費されるような状況では逆効果です。
また、読みだしスクリプトを書き換えるだけでも性能向上を行える場合もありますので、差し支えなければ使用している読みだしスクリプトを見せてもらえれば、いろいろ工夫できるかもしれません。


添付ファイル: SmallKinoko-RemoteDaq.kcom (10.9 kb)


読み出しスクリプト
2007 年 8 月 30 日 13 時 24 分
投稿者: 平野

アドバイスありがとうございます。
性能が向上するか分かりませんが、Collectorを別のPCにして
挑戦してみます。動作報告は後日させていただきます。

読み出しスクリプトを添付しましたので、何かアドバイスが
あればよろしくお願い致します。

添付ファイル: readout.tar.gz (7.6 kb)


無題
2007 年 9 月 18 日 13 時 49 分
投稿者: 榎本 三四郎

読みだしスクリプト、module-CAEN-C205 ともに、特に問題は
ないと思います。あえて言えば、kts の中で transact() は若干遅いので、C205 のコードを改変して、例えば clear() などに組み込むことができれば、(ほんの僅かですが)速度があがるかもしれません。
(もともと、transact() はモジュールドライバを書かなくてもCAMAC
をすぐに使えるようにするためのもので、速度は重視していません)。

そうすると、1100 cps のうち 200 cps しかとれないというのは、やはり読みだしレートが高いからでしょうか? 今の kts では、一回トリガがかかると 100 回くらい CAMAC アクセスを行っていますので、CAMAC アクセス数では 20 k cycles/sec となって、かなり良いほうなのではないかと思います。

このレートでは、すでに CAMAC が限界に来ている可能性があるので、Collector を別にして性能が上がるかは微妙なところです。もう遅いかもしれませんが、これを試す簡単な方法は、tinykinoko をデータファイル指定なしで実行することです。これにより、ディスクやネットワークに影響されずにデータ読みだしができるので、本当の限界を知ることができます(これであまり変化がなければ、Collector を別にしても改善は望めない)。

一つ、CAMAC 自体を高速化する方法として、ブロック読みだしを
実装するという手があります。標準的なインターフェースが規定されていないので、camdrv では実装していませんでしたが、もし必要なのであれば camdrv を改造してみたいと思いますが、いかがでしょうか? 
(ただ、最近は異常に忙しい状態が続いていますので、おそらく数ヶ月後ということになってしまうと思います。)


このスレッドに記事を投稿する