どくた合宿 99 今年中に取る手法とその… 杉浦 一徳 [email protected] 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 • ドクタを完成させるプロセス 後期博士課程 セミナー発表 生活支援型インターネットを実現させる 協調型システムアーキテクチャモデルの研究 杉浦 一徳 [email protected] 1999年03月10日 本研究の目的 本研究の目的 • オペレーティングシステムとアプリケーションの 協調動作 • Application Aware なオペレーティングシステム の実現 – デバイス、ネットワークの状態情報を抽象化 – APM：HDD、CPUやPCMCIAと電源管理に関する情報 – ネットワーク：輻輳、遅延や切断などの状態に関する情報 – 統一的な手法でアプリケーション、ユーザに提供 – ネットワーク及び，計算機環境の動的な変化に対し てアプリケーションおよびユーザが適応処理を行う 発表内容 • 現在のインターネットアーキテクチャ – オペレーティングシステムの役割とアプリケー ション • Application Awarenessという視点から見た 現在のアーキテクチャの問題点 • Application Aware Operating Systemの開 発 次:App aware な OS Application Aware なオペレーティングシステム Internet ルータ ルータ PC 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 State handling Library Application State Handler Daemon Application ユーザー空間 メッセージパッシング カーネル空間 State Handler TCP/IP Scheduler Device APM 次:state handlerの役割 State Handler • オペレーティングシステムの持つ • 状況(state) • 資源 – をアプリケーションに統一した形でメッセージ パッシングとして，通達する． – デバイス，モジュールからの状況情報をメタ データベースとして保持する． 次:メッセージパッシング メッセージパッシング • State Handlerからアプリケーションへの • メッセージパッシング – Signalの利用． • 単一メッセージの報告(状況変化) • アプリケーションは必要に応じて問い合わせ State handling Library Application State Handler Daemon Application 次 :daemon State Handler State Handler Daemon – カーネル空間のState Handlerの持つ情報をアプリ ケーションに通達するためのデーモン – 「state」の内容について統一的なアクセス方式を デーモンから提供． – 柔軟性を確保 • state oriented Application Libraryの作成 State handling Library Application State Handler Daemon Application State Handler Stateの抽象化 • ある程度，統一されたカテゴライズが必要 – ネットワークの状態: • データストリームのバースト転送力 • 平均データ転送能力 • Congestion Notification(ECN) • 電源の状態 • ○○の状態 • 状態の種類の多様性の対処方法 状態の追加 • アプリケーションには統一されたメッセージ パッシングのみが行われる． – アプリケーション側からは， • メッセージパッシングを無視 • メッセージの詳細をState handler daemonに聞く – 状態の追加に対するアプリケーションの対応 は不変 応用例1: APM • 変化する事象: APM のSMI(System Management Interrupt)の制御 節電機能によるシステムの動作変化 電力消費によって抽象化したアーキテク チャの開発 バッテリー容量を把握 応用例2:インターネットによる DV映像の送信 IEEE1394 IEEE1394 Internet IP IP 状況に応じたデータストリームの 処理機能の実現 • Full rate digital video stream • Half rate digital video stream • 1/3 rate digital video stream DV Packet with Audio DV Packet without Audio Frame Video data in frame audio data in frame 次:アプリケーション開発の例 アプリケーション開発の例: • 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(RTMach 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 おしまい
© Copyright 2025 ExpyDoc
