KONOEデータフロー階層
1.はじめに
オンラインシステムの重要な機能はデータ収集です。データは実験時にはCAMACなどの
実験装置インターフェースから読み込まれ、ディスクやテープなどに保存されると
ともに、オンラインで解析され、表示されたりヒストグラムが作られたりします。
これらは実験データの転送を伴います。
ここでのデータ転送は、通常非常に高速性を要求します。データ転送の効率は
システム性能を決める非常に重要なパラメータです。そのために、できるだけ
効率的な転送手法を使いたいものです。
一方で、KONOEでは実験データもオブジェクトとして扱われます。そのために、
転送されるのはオブジェクトということになります。この場合、オブジェクトの
ストリーム化は非常に汎用性の高い方式で行われます。そうすると、冗長な、
無駄の多い書式付けがされることになっています。このことは検討を必要とします。
2.データ転送経路の確保
データ転送はソケット通信を使って行われます。
通常はTCPソケットが割り当てられます。ソケットへの送出のシステムコールは
その都度オーバーヘッドをかぶることになってしまいます。アプリケーション側での
バッファリングは必要です。TCPソケットのペイロードに当たるサイズがたまった
ところで転送を起動するようにします。
送信と受信が完全に同期することは難しいので、システム自身が待ち行列を用意
します。例えば、受信側の処理が遅れていると送信側の待ち行列に大量のデータが
たまってしまいます。効率的にシステムを運用するためには、こういった状況が
ちゃんと監視されていなければなりません。
3.効率的なデータ転送のために
できれば、汎用のオブジェクトストリーム化機構を使いたいのですが、大量の
データ転送を行う場合、そのオーバーヘッドが馬鹿にならないことがあります。
例えば、1ワードの整数を送るために3ワードのヘッダーをつけるといった具合に。
これは、非常にたくさんの種類のオブジェクトが交換される場合にはやむを得ない
ことですが、実験データ転送のように、生データを入れたコンテナオブジェクトの
場合、送られるクラスの種類はそれほど多くありません。実際、現在のKONOEの
スキームでは4種類にすぎません。いったん、あるソケットで送られるクラスの
種類が決まってしまえば、もっと簡略化された書式で十分です。それによって、
転送効率を向上させることが可能でしょう。そのようなスキームを検討すべきです。
概要へ戻る
目次へ戻る 次章「KONOEを構成するプロセス」へ
[intro/dataflow.html] Last Modified : 13-Mar-2001.
KONOEコラボレーション
konoe-req@konoe.kek.jp