松坂様

栗原です。

以下は、一つのExecutionContextに対して複数のRTCが登録された場合についてです。

> ・ExecutionContextは直列リストの構造をしている。
ExecutionContextは、add_component(rtobj)にて登録されたRTCをリストで管理してお
り、whileループの中では、リストに登録されているRTCのアクティビティ処理を呼び出し
ます。(正確には、StateMachineから呼ばれます。)

> ・ただし、あくまで分散コンポーネントモデルなので中央でコンテキストを管理している
> 　サービスがあるわけではなく、各コンポーネント同士がバケツリレーのような形で
> 　実行タイミングを通知しあっている。
RTCのリストに登録してある順番でRTCのon_execute()などを呼びますので、たとえば、
３つのRTC(A,B,C)が登録されていて、３つのRTCがACTIVE状態であれば、Aのon_execute
()が戻ってきて、Bのon_execute(),Cのon_execute()のようになります。
よって、各コンポーネント同士が実行タイミングを通知しあっているのではなく、
あるRTCのアクティビティ処理が終了次第、次のRTCのアクティビティ処理の実行をECが
行うといった仕様になっております。

以上、宜しくお願い致します。

On Tue, 6 Jul 2010 17:44:54 +0900
Yosuke Matsusaka wrote:

> 栗原さん
>
> 松坂です。
>
> 2010/7/6 kurihara shinji :
> > RTMでは、一つのExecutionContextで複数のRTCを駆動する事が可能となっております。
> > 仮に、非アクティブ状態でループを回さないようにした場合、一つのECに複数のRTC
> > が関連付けられてる状況において、一つの RTC が非アクティブ状態の時に、他のアク
> > ティブ状態のRTCまでも駆動関数(on_execute)が実行されないといった事になってしまい
> > ます。
> >
> > 上記のような理由もあり、ExecutionContextのループは、RTCの状態に関わらずループ
> > する仕様となっております。
>
> なるほど、理解しました。
> 金広さん、清水さんの議論を読んで、何となく私の理解がずれている予感がしていたのですが、
> これでクリアになりました。
>
> ・ExecutionContextは直列リストの構造をしている。
> ・ただし、あくまで分散コンポーネントモデルなので中央でコンテキストを管理している
> 　サービスがあるわけではなく、各コンポーネント同士がバケツリレーのような形で
> 　実行タイミングを通知しあっている。
>
> というわけですね。
> 改良しようとしてもなかなか難しいところですね、、、。
>

金広様

栗原です。

Python版では、RTCが非アクティブ状態であってもサービスポートを有効にする事は可能
です。
ただし、OpenRTM-aist-0.4の頃に、「RTCが非アクティブの時はサービスポートも無効に
した方がよい。」という要望があり、1.0.0からはRTCが非アクティブの時はサービスポー
トも無効とするような変更が行われた経緯がございますので、今回紹介させて頂く方法が
良いのかは保証できません。

サービスポートを有効にする方法としましては、CorbaPort::activateInterfaces()を
呼ぶ事で有効になります。
ただし、このメソッドは、C++ではprotectedで宣言されてますので、RTCからは呼ぶ事
ができません。
Pythonでは可能です。

OpenRTMのサンプルに含まれますMyServiceProvider.pyを変更し、RTCが非アクティブ状態
でもサービスポートを使用できる事を確認致しましたので、添付させて頂きます。

添付のRTCでは、ECの停止と、サービスポートの有効化を行っております。

以上、宜しくお願い致します。

On Tue, 6 Jul 2010 14:41:17 +0900
Fumio Kanehiro wrote:

> 松坂様，栗原様，
>
> 回答ありがとうございました．
> ConsoleIn.pyの中身を見ていなかったので勘違いしたようです．
>
> 松坂さんの要望に関連するのですが，ExecutionContext無しのRTCというのは
> 作れないものでしょうか？というのは時々サービスポートだけを持っていて，
> onExecute()では何もしない，単なるCORBAサーバのようなRTCを作りたい時が
> あるのです．この場合ExecutionContextは何もせずに回っているだけで無駄に思えます．
> （ただし1.0.0-RELEASEからRTCがACTIVE状態でないとサービスポートは
> 有効でないようですので，EC無しにではサービスポートも使えなくなって
> しまいますが）
> 何かいい方法は有りますでしょうか？
>
>
> 2010/7/6 kurihara shinji :
> > 金広様
> >
> > お世話になっております。
> > 栗原です。
> >
> > 先程の「INACTIVE状態ではACTIVE状態に比べCPU負荷が高くなっておりました」
> > という内容には補足が抜けておりました。
> > こちらで確認しましたコンポーネントは、ConsoleIn.pyでして、ACTIVE状態で
> > は標準入力からの入力待ちとなるため、INACTIVE状態ではACTIVE状態よりもCPU
> > 負荷が高いと表現致しました。
> > 誤解を招く表現をしてしまい、申し訳ございません。
> >
> > ご指摘の通り、実際は、onExecute()にて何らかの処理を実装している場合、
> > INACTIVE状態よりもACTIVE状態の方が負荷は高くなります。
> >
> > ConsoleIn.pyのonExecute()にて、すぐに"return RTC.RTC_OK"にて何も処理を
> > 行わないように変更し確認しましたところ、INACTIVE状態とACTIVE状態とでは
> > 負荷はほぼ同じでした。
> >
> >
> > 以上、宜しくお願い致します。
> >
> >
> > On Tue, 6 Jul 2010 14:18:51 +0900
> > Fumio Kanehiro wrote:
> >
> >> 栗原様，
> >>
> >> 金広＠産総研です．
> >>
> >> 参考までになぜINACTIVE状態の方がACTIVE状態よりもCPU負荷が高くなるのか教えて
> >> いただけないでしょうか．
> >> ExecutionContextはRTC内のステートマシンの状態によらず動作しているため，RTCが
> >> INACTIVEでもCPUを食うのはわかるのですが，ACTIVE状態のほうがonExecute()を
> >> 実行する分だけ負荷が高くなるように思えるのですが．
> >>
> >> 2010/7/6 kurihara shinji :
> >> > 松坂様
> >> >
> >> > お世話になっております。
> >> > 栗原です。
> >> >
> >> > ご連絡、有難うございます。
> >> > こちらで確認しましたところ、ご指摘頂きましたように、INACTIVE状態ではACTIVE状態に
> >> > 比べCPU負荷が高くなっておりました。
> >> >
> >> > これは、RTCの実行コンテキスト(PeriodicExecutionContext)がwhileループを回してい
> >> > るためでして、whileループ内ではデフォルトで 0.001 秒の sleep が入りますが、0.001
> >> > 秒の sleepでは cpu負荷が少々高くなるようです。
> >> > sleep時間を0.01秒にする事で負荷は約半分に軽減される事を確認しました。
> >> > # sleepが無い場合は、CPUは90%近くなります。
> >> >
> >> > 1msecでコンポーネントを実行する必要が無い場合は、お手数ですが、rtc.confファイル
> >> > に以下の一行を追記して、ご確認頂けますでしょうか。
> >> >
> >> > exec_cxt.periodic.rate: 10 # 10Hzです。
> >> >
> >> >
> >> > 以上、宜しくお願い致します。
> >> >
> >> >
> >> > On Tue, 6 Jul 2010 11:22:05 +0900
> >> > Yosuke Matsusaka wrote:
> >> >
> >> >> OpenRTM-aist開発者の皆様
> >> >>
> >> >> 産総研の松坂です。
> >> >>
> >> >> Python版のOpenRTM-aistに特有の問題ですが、コンポーネントがアクティブ状態にないときに
> >> >> CPU負荷が上昇する現象に遭遇しています。
> >> >> 私の環境だけかもしれませんが、確認してみていただけますでしょうか？
> >> >>
> >> >> 以下、再現方法です。
> >> >> １．適当なPythonコンポーネントを起動（私は添付のスクリプトを使用しましたがそれ以外でも再現します）
> >> >> ２．コンソールでtopコマンドを入力（この時点でPythonコンポーネントの負荷が10%程度に上昇しているのが確認できます）
> >> >> ３．RTSystemEditor上でコンポーネントをアクティベート（Pythonコンポーネントの負荷が数%に低下）
> >> >> ４．RTSystemEditor上でコンポーネントをデアクティベート（Pythonコンポーネントの負荷が10%程度に上昇）
> >> >>
> >> >> 私の開発環境の詳細です。
> >> >> VMWare使用
> >> >> ホストPC：MacOS X (snow leopard)
> >> >> ゲストPC：Ubuntu 10.4
> >> >> OpenRTM：1.00-release （debパッケージ）
> >> >>
> >> >> もし何かわかりましたら教えてください。
> >> >>

松坂様

栗原です。

> そうでしたか、、、少し前まではpriodic.rateはソースの中に書けていたと思うので
> おかしいなと思っていました。
申し訳ございません。
確かに、少し前まではperiodic.rateはソースの中に書いた値が反映されており、先程の
優先順位の通りにはなっていなかったのですが、1.0.0-RELEASEでは、先程の優先順位の
通りになるように修正が入りました。(C++版も同様です。)

> 「[コンポーネント名].confファイル」は、どのフォルダにあるものが読まれるのでしょうか？
> カレントディレクトリのみであれば私の用途だと使えないですが、rtc.confと同じように/etcに
> 置いたものも探して読んでくれるのであれば、うまく使えるかもしれません。
以下のようにフルパスで記述する事で、ファイルがどこにあっても読み込まれます。

# rtc.conf
corba.nameservers: localhost
naming.formats: %n.rtc
logger.enable: NO
example.ConfigSample.config_file: /tmp/configsample.conf

# /tmp/configsample.conf
exec_cxt.periodic.rate: 10

[コンポーネント名].confファイルにつきましては、ConfigSample,Compositeサンプルあ
たりを参考にしていただければ幸いです。

以上、宜しくお願い致します。

On Thu, 8 Jul 2010 16:46:43 +0900
Yosuke Matsusaka wrote:

> 栗原さん
>
> 松坂です。
>
> 2010/7/8 kurihara shinji :
> > 以下の８つにつきましては、rtc.conf(もしくは、DefaultConfiguration.py)
> > 、もしくは、createComponent()の引数で指定する事になっております。
> >
> > "exec_cxt.periodic.type",
> > "exec_cxt.periodic.rate",
> > "exec_cxt.evdriven.type",
> > "logger.enable",
> > "logger.log_level",
> > "naming.enable",
> > "naming.type",
> > "naming.formats"
>
> そうでしたか、、、少し前まではpriodic.rateはソースの中に書けていたと思うので
> おかしいなと思っていました。
>
>
> > あと、追加情報ですが、以前のRTCBuilderでは、生成されたソース
> > に"exec_cxt.periodic.rate" が書かれておりましたが、最新版のRTCBuilder
> > では、rateを指定した場合、ソースではなく[コンポーネント名].confファイル
> > に出力されるようになりました。
>
> 「[コンポーネント名].confファイル」は、どのフォルダにあるものが読まれるのでしょうか？
> カレントディレクトリのみであれば私の用途だと使えないですが、rtc.confと同じように/etcに
> 置いたものも探して読んでくれるのであれば、うまく使えるかもしれません。
>
>
> > もし、ソースに埋め込みたい場合は、以下のようにcreateComponent()の引数
> > にて指定する事は可能です。
> >
> > # Create a component
> > comp = manager.createComponent("ConfigSample?exec_cxt.periodic.rate=1")
>
> ありがとございます。とりあえずはこれで行こうと思います。
>