どくた合宿 99 今年中に取る手法とその … 杉浦 一徳 1999 年 03 月 10 日 本研究の目的

今後の進め方について， サーベイ –R3 プロジェクト， MKng プロジェクト ミドルウェア カーネルトレイ ( たつおさんとか …) QoS MIB, SNMP との関係． – 土俵 ( 外側 or 内側 only?) – 環境情報デーモン (uhyoD) – 粒度 – 時間の関係 ( サンプリング，過去，予測 ?)

グルーピング ( カテゴライズ ) –data flow –hardware specific status(condition) hardware interrupt –trapping –trigger

今までやってきたのを –uhyod ベースに作り直す． 定数，変数，ダイナミックリファレンス uhyod だからとれる物． 時間． – 分類分け カテゴリとの関係． USENIX との関係．

進め方 一歩先に進める． – もう一本の論文内容 環境情報デーモンと，そのインタプリタ trap と， interrupt – 知りたいこと :

具体的な話

今の課題 CRL 情報処理学会 論文誌 (4 月末締め切 ) 次の論文誌の内容 進め方 ( 方針 )

必要な事 システムの状態を表現する手法． – オペレーティングシステムから App に対し て 状況を伝える手法 ( アッパレイヤに対して ) 現状の ( 人間が対応する ) に勝つ方法． マネジメント – 的を絞る方法 : 評価基準を考える ?( マクロ ) – ネットワーク – バス – プロセッサ – インターフェース ( バッテリ ? Etc….) シグナリングをする必要性をどこで判断するの か ?

おさむさん システムの状態を見る –SNMP 色々な状態を監視したい MIB で表現 – 見たい物 クラス，オブジェクト – 見せる物 割り込み (Interrupt) と割り出し (Trap) 非同期のコミュニケーション –Asynchronous Message Passing

Event Driven System – 状態遷移図で OS がかければ問題ない． –State handling –signaling の数 多くなると –race condition…. –Dead locking…. –Infinite Loop…. –Application が欲しい物 → アプリしか欲しく ない． –Event description Language.

Murai さんの … タイミング・

Definition – 管理する対象 – 定義 – 記述方法 粒度 状態遷移 – 状態を知る方法 プロトコル – プロセス OS に対して割り込みを定義できる

メタ記述言語 うひょ D – 標本 – インタプリタ その記述方式 – 汎用性 ( –global variable で得られる情報を提供

uhyod 状態の把握． – 相手の状態も知りたいの ? –Uhyod uhyop uhyod – ぼんやりとした空間を ぼんやりしてる ! と伝える． – コミュニケーション – 仲介役 環境情報 D ドクタを完成させるプロセス

後期博士課程 セミナー発表 生活支援型インターネットを実現させる 協調型システムアーキテクチャモデルの研究 杉浦 一徳 1999 年 03 月 10 日 本研究の目的

オペレーティングシステムとアプリケーショ ンの協調動作 Application Aware なオペレーティングシステ ムの実現 – デバイス、ネットワークの状態情報を抽象化 –APM ： HDD 、 CPU や PCMCIA と電源管理に関する情報 – ネットワーク：輻輳、遅延や切断などの状態に関する情報 – 統一的な手法でアプリケーション、ユーザに提 供 – ネットワーク及び，計算機環境の動的な変化に 対してアプリケーションおよびユーザが適応処 理を行う

発表内容 現在のインターネットアーキテクチャ – オペレーティングシステムの役割とアプリ ケーション Application Awareness という視点から見 た現在のアーキテクチャの問題点 Application Aware Operating System の開 発 次 :App aware な OS

Application Aware なオペレーティングシステム ルータ PC Internet PC

アプリケーションの動作 コンピュータの持つ資源を利用 – ハードディスク – メモリ –CPU – ディスプレイ – キーボード – マウス 次 :OS の役割

オペレーティングシステム の役割 資源の管理と提供 プロセス管理・スケジューリング デバイス管理 ( 簡素化した入出力イン ターフェースの提供 ) イベントロギング ( ハンドリング ) ê アプリケーション ( ユーザ ) に対して抽象 化、隠蔽

時代の変化とともに 利用形態 状況に応じて変化する環境 –APM –PCMCIA カード –1394 – ネットワーク

APM APM で提供する機能 – 電池の残量 –APM によって管理されるデバイスの状態 (state) 動作速度 動作状態 –ON –Power Managed –Low Power –Off

PCMCIA PCMCIA で提供する機能 –PCMCIA デバイスの種類 ( ネットワークなの か，ストレージなのか．．． ) – デバイスの Ioport IRQ –device state

IEEE1394 高速シルアルインターフェース Isochronous 転送のサポート 抜き差しに動的に適応する Bus Reset メカニズム IEEE1394 を用いたホームネットワーク –HAVi –HWW

ネットワーク・インターネッ ト Best effort 型のネットワーク – アプリケーションにとっては，ネットワー クに転送する情報は宅急便 … どのように扱われるかは，分からない アプリケーションとの協調を前提とし たい新しいプロトコル体系 –RED RED+ECN –RTP + RTSP

これらの共通する点 : – 動作状態が絶えず変化する． 状態の変化 – ネットワークの輻輳 – 節電機能による処理変化 – 動作できない状況になりうる． – ネットワークの切断 – 動作する必要のない時がある． 利用する環境の状態を知る必要性 デバイス，ネットワークから見ると，ユーザ ( アプリケーション ) からの対応が必要になっ てきた．

これらの必要性に対する 現状の問題点 ユーザ ( アプリケーション ) からカーネル 内部の状態情報の取得が困難 – シグナリング ê 取得できる情報は限定されている – ポーリング ê 動的な状態取得ができない ê ユーザの積極的な対処 êOS の Application Unawareness 結果として

シグナリング OS からユーザにシステムイベント情報 を通達する機能 オペレーティングシステムが機能する 上でのアプリケーション側が行った違 反の通達 アプリケーションの停止，再会，中断， 終了

ポーリング 一定期間毎の情報収集 –kmem から得られる情報のポーリング – レジストリから得られる情報のポーリング – 統一されたインターフェースが提供できな い – 変化の動的な検知は不可能． イベントハンドリングではない． 結局，効率的な方法は，ユーザの認識

ユーザの積極的な確認手法 user-aware なインターフェース ユーザが状態の変化を認識し，その管 理を行う 状況を判断する能力が問われる． – 状況を常に認識できれば，問題はない …

現在のオペレーティングシステ ムの問題点 Application Unawareness – ユーザ ( アプリケーション ) は OS の管理する 資源の状態情報を利用できない – 計算機環境の状態変化に適応したアプリ ケーションサービスの提供ができない Application Unawareness = Programmer Unawareness – アプリケーション開発にも支障が生じる．

アプリケーション開発環境か ら見た問題点 アプリケーションを開発する視点 – 開発者は : – 状況に対応したアプリケーションの作成が したい． 状況の変化に応じたライブラリの作成 – 電池残量に応じたアプリケーションの動作変化 – ネットワークスループットに応じたデータストリー ムの変更 状況 (State) をどのような形で抽象化するかが，問題 : 状況の持つ多様性

本研究での解決策 オペレーティングシステムとアプ リケーションの協調機構を実現 (Application Aware Operating System) – デバイス，ネットワークの変化する状況を 統一的な手法でアプリケーションに通達 –OS からの通達に応じた対応にアプリケー ションは協力 携帯型計算機の有効な資源利用 ネットワークの輻輳制御 OS からアプリへ状態変化の通達

状態変化の通達 ( 設計 ) アプリケーションに対して 変化した状態情報を提供・未来の状態を想定し提供 À メッセージパッシング メタな情報の提供方法としてメッセージパッシング を行う． 具体例 : シグナル 「状況変化」という事象のみの報告 ­ システムコールによる状態の取得 getstate → メタ関数 ® アプリケーション、ユーザによる対応動作 次 : 全体の構成図

Application Aware OS Device TCP/IP APM Scheduler State Handler Application State Handler Daemon State handling Library メッセージパッシング カーネル空間 ユーザー空間 次 :state handler の役割

State Handler オペレーティングシステムの持つ 状況 (state) 資源 – をアプリケーションに統一した形でメッ セージパッシングとして，通達する． – デバイス，モジュールからの状況情報をメ タデータベースとして保持する． 次 : メッセージパッシング

メッセージパッシング State Handler からアプリケーションへの メッセージパッシング –Signal の利用． 単一メッセージの報告 ( 状況変化 ) アプリケーションは必要に応じて問い合わせ State Handler Application State Handler Daemon State handling Library

State Handler Daemon – カーネル空間の State Handler の持つ情報をアプリ ケーションに通達するためのデーモン – 「 state 」の内容について統一的なアクセス方式を デーモンから提供． – 柔軟性を確保 state oriented Application Library の作成 State Handler Application State Handler Daemon State handling Library

State の抽象化 ある程度，統一されたカテゴライズが必要 – ネットワークの状態 : データストリームのバースト転送力 平均データ転送能力 Congestion Notification(ECN) 電源の状態 ○○ の状態 状態の種類の多様性の対処方法

状態の追加 アプリケーションには統一されたメッ セージパッシングのみが行われる． – アプリケーション側からは， メッセージパッシングを無視 メッセージの詳細を State handler daemon に聞く – 状態の追加に対するアプリケーションの対 応は不変

応用例 1: APM 変化する事象 : APM の SMI(System Management Interrupt) の制御 節電機能によるシステムの動作変化 電力消費によって抽象化したアーキテ クチャの開発 バッテリー容量を把握

応用例 2: インターネットによ る DV 映像の送信 Internet IEEE1394 IP

状況に応じたデータストリー ムの処理機能の実現 Frame Video data in frame audio data in frame Full rate digital video stream Half rate digital video stream 1/3 rate digital video stream DV Packet with Audio DV Packet without Audio 次 : アプリケーション開発の例

アプリケーション開発の例 : APM: – 電池容量警告シグナルのためのライブラ リー開発 通常モードと Green モード ネットワーク : –ECN 検知によるデータストリームの容量変 更

応用例② ホームネットワー ク インターフェース技術 USB(Universal Serial Bus), IEEE1394 HomePNA(Phoneline networking Appliance) CDMA( 無線 LAN) = HomeRF AC-LAN = PLANET インターネットチップ iReady Internet Tuner Chip ホームネットワーク HAPI(Home API) HAVi(Home A/V Interoperability)

ホームネットワーク機器から 取得できる状態情報 何がつながるのかは未知数 提供される情報としては， デバイスタイプ データストリームのパケット数 ( 量 ) 次 : 関連研究

関連研究 APM の応用， Application awareness Scheduling for Reduced CPU Energy(USENIX) Application-Aware Adaptation for Mobil Computing(ACM) Application aware Operating System System Support for Mobile Multimedia Applications(John Inouye NOSSDAV 97) System Support for Mobility(John Inouye ACM SIGOPS 96) Network and Application Oriented Network Support for Application Oriented OS( Peter Steenkiste(ICNP 98)

本研究の特徴 本研究の着目点 Application Awareness – アプリケーションが利用するネットワーク， 資源に対して : アプリケーションが能動的になるべき もっとアプリケーション側から制御するべき – メッセージパッシングの方法 統一的な方法で状況をアプリケーションに伝え る

本研究の評価方針 state driven と， 従来の方式による – ネットワークの効率的な利用 – 電力の効率的な利用 Object Oriented OS ・ Module OS との比較 Apertos Inferno RTMach with QoS Server オーバーヘッド massive alert(signal) の対応 Race Condition(Alert loop)

Massive Alert 状態変化の粒度． 状態の抽象度のレベル – 細かくしすぎると，常に状態の報告を行うようにな る． オーバーヘッドとの兼ね合い –State の抽象度 – アプリケーション開発における視点 alert を積極的に受け入れるか 徹底的に無視するか

現在までの研究 APM とオペレーティングシステム Power Management for Portable Computers(RT- Mach Workshop) Abstract of demand based Operating Systems 携帯型計算機の有効な資源利用 ( 情報処理学会 コンピュータシステムシンポジウム ) DV Over IP Design and Implementation of DV Stream over Internet (IWS)

研究プロセス IEEE Mascots(5/1) Transferring DV Stream Over Internet Using Application Aware Operating Systems ACM MultiMedia Design of Universal Translation Gateway

おしまい