JP2001043094A - マイクロスケジューリング方法及び運営体制カーネル - Google Patents

Abstract

(57)【要約】 【課題】 マルチメディアを支援するためのＱｏＳ要件
を満足させるマイクロスケジューリングアルゴリズム及
びそれを具現する運営体制カーネルを提供する。 【解決手段】 本マイクロスケジューリング方法は
（ａ）与えられたアプリケーションに対してパフォーマ
ンスパラメータを求める段階と、（ｂ）予め設定したポ
リシーによりパフォーマンスパラメータを適切に調整す
る段階と、（ｃ）マルチメディアアプリケーションの特
性上ユーザー空間へのデータ移動が要らないデータに対
して周期的に入出力作業を遂行するようにスケジューリ
ングして、アプリケーションクラスに対する処理の優先
順位を決定する段階と、（ｄ）前記（ｃ）段階により決
定された優先順位によってスペシャルＩ／Ｏシステムコ
ールを遂行する段階とを含むことを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はマイクロスケジュー
リングアルゴリズムに係り、さらに詳しくはマルチメデ
ィア支援を必要とする運営体制に適合したマイクロスケ
ジューリングアルゴリズムに関する。また、本発明は前
記マイクロスケジューリング方法を具現する運営体制カ
ーネルに関する。

【０００２】

【従来の技術】ユニックス（Ｕｎｉｘ:登録商標）、リ
ヌックス（Ｌｉｎｕｘ:登録商標）、及びウインドウズ
ＮＴ（ＷｉｎｄｏｗｓＮＴ:登録商標）のような運営体
制はマルチユーザーを支援するために１０ミリ秒程度の
タイムスライス（ｔｉｍｅ ｓｌｉｃｅ）を有するタス
クスケジューリング（ｔａｓｋ ｓｃｈｅｄｕｌｉｎ
ｇ）方式を用いている。マルチメディアを支援するため
にはＱｏＳ（ｑｕａｌｉｔｙｏｆ ｓｅｒｖｉｃｅ）要
件を満足する機能を運営体制及びネットワークから支援
しなければならないが、複数個のアプリケーションを処
理するならばマルチメディアデータを処理する途中にも
定まったタスクスケジューリングによって継続的なイン
タラプトが発生されるのでマルチメディアデータの処理
が連続的であらずショートが生じる。すなわち、従来の
運営体制で用いられるスケジューリング方式ではマルチ
メディアを支援するためのＱｏＳ要件を満足し難いとい
う問題点がある。

【０００３】前記問題点を解決するための他の従来技術
によると、共有ヒープ（ｈｅａｐ）を構成することのよ
うに運営体制において重要なプロセスの構造を変形する
ために既存ソフトウェアとの互換性を喪失するという問
題点がある。また、前記問題点を解決するためのさらに
他の従来技術によると、ＥＤＦ（Ｅａｒｌｉｅｓｔ Ｄ
ｅａｄｌｉｎｅ Ｆｉｒｓｔ）等のようなリアルタイム
スケジューリングアルゴリズムを適用する場合にはアド
ミッション制御（ａｄｍｉｓｓｉｏｎ ｃｏｎｔｒｏ
ｌ）、逆方向互換性（ｂａｃｋｗａｒｄ ｃｏｍｐａｔ
ｉｂｉｌｉｔｙ）維持、非正常的なＱｏＳ違反等によっ
て性能が著しく低下される場合があり、過負荷状態では
既に保証したサービス品質さえも達成されない場合が生
じるという問題点がある。

【０００４】

【発明が解決しようとする課題】本発明が達成しようと
する技術的課題は、マルチメディアを支援するためのＱ
ｏＳ要件を満足させるマイクロスケジューリングアルゴ
リズムを提供することにある。本発明が達成しようとす
る他の技術的課題は、前記マイクロスケジューリングア
ルゴリズムを具現する運営体制カーネルを提供すること
にある。

【０００５】

【課題を解決するための手段】前記課題を達成するため
の本発明によるマイクロスケジューリング方法は、マル
チメディアアプリケーションを支援するための運営体制
カーネルで具現されるスケジューリング方法において、
（ａ）与えられたアプリケーションに対して入出力Ｉ／
Ｏバウンド作業ＪＯＢパフォーマンス及びＣＰＵバウン
ド作業ＪＯＢパフォーマンスを測定することによってパ
フォーマンスパラメータを求める段階と、（ｂ）システ
ム管理者が作業ＪＯＢアドミッション制御を遂行するこ
とによって予め設定したポリシーによってパフォーマン
スパラメータを適切に調整する段階と、（ｃ）前記パフ
ォーマンス測定と作業ＪＯＢアドミッション制御を基礎
に、マルチメディアアプリケーションの特性上ユーザー
空間へのデータ移動が要らないデータに対して周期的に
入出力作業ＪＯＢを遂行するようにスケジューリングし
て、アプリケーションクラスに対する処理の優先順位を
決定する段階と、（ｄ）前記（ｃ）段階により決定され
た優先順位によってスペシャルＩ／Ｏシステムコールを
遂行する段階とを含むことを特徴とする。

【０００６】また、前記（ａ）段階は、アプリケーショ
ンのクラスに適合したテストプログラムを用いて与えら
れたアプリケーションに対して入出力Ｉ／Ｏバウンド作
業ＪＯＢパフォーマンス及びＣＰＵバウンド作業ＪＯＢ
パフォーマンスを測定することによってパフォーマンス
パラメータを求めることが望ましい。また、前記（ｂ）
段階は、前記（ａ）段階で求めたパフォーマンスパラメ
ータとアプリケーションクラスとに対する処理の優先順
位及びポリシー記述表でシステム管理者が設定したリソ
ース割り当てを基礎とするエンタープライズサービス品
質ＱｏＳモデリングによって遂行されることが望まし
い。

【０００７】また、前記方法は可用性テストを遂行する
段階と、アドミッション制御及びリソース予約を遂行す
る段階と、システムリソースに対して各アプリケーショ
ン別デフォルト及び最大範囲を決定するためのポリシー
を記述する段階と、ＣＰＵバウンドパフォーマンスに対
する測定を遂行する段階と、入出力Ｉ／Ｏバウンドパフ
ォーマンスに対する測定を遂行する段階をさらに含むこ
とが望ましい。また、前記スペシャルＩ／Ｏシステムコ
ールは、ユーザー空間から装置にデータを移動させる入
出力Ｉ／Ｏサービスクラス１、ユーザー空間からユーザ
ー空間にデータを移動させる入出力Ｉ／Ｏサービスクラ
ス２、ユーザー空間にデータをやり取りする入出力Ｉ／
Ｏサービスクラス３、及び装置から装置にデータを移動
させる入出力Ｉ／Ｏサービスクラス４の４種のクラスに
区分される入出力Ｉ／Ｏ作業ＪＯＢにおいて、マルチメ
ディアアプリケーションに現れる場合のある入出力Ｉ／
Ｏサービスクラス４をスペシャルＩ／Ｏに該当する作業
ＪＯＢであると決定して、アプリケーションで遂行する
作業ＪＯＢがスペシャルＩ／Ｏに該当する場合に前記ス
ペシャルＩ／Ｏスケジューリング手段により配分された
リソースによって周期的な入出力を担当することが望ま
しい。

【０００８】また、前記スペシャルＩＯは、ディスクフ
ァイルからネットワークにまたはネットワークからディ
スクファイルに入出力を遂行するスペシャルＩＯクラス
１、入出力Ｉ／Ｏ部からネットワークにまたはネットワ
ークから入出力Ｉ／Ｏ部に入出力を遂行するスペシャル
ＩＯクラス２、及びアプリケーションから／に入出力を
遂行したりスレッド（ｔｈｒｅａｄ）からスレッドにま
たはループバック（ｌｏｏｐ−ｂａｃｋ）形態で入出力
を遂行するスペシャルＩＯクラス３の３種のクラスに区
分されることが望ましい。また、前記（ｃ）段階でスケ
ジューリングに用いられるタスクＱは、スペシャルＩＯ
クラス１のアプリケーションに関連したミディアムＱ
（ＭＱ）、スペシャルＩＯクラス２及び３のアプリケー
ションに関連したハイＱ（ＨＱ）とスペシャルＩＯクラ
ス４のアプリケーションに関連したローＱ（ＬＱ）の３
種に区分されることが望ましい。

【０００９】また、前記（ｃ）段階は、前記スペシャル
ＩＯクラス２とスペシャルＩＯクラス３のＪＯＢの場合
にスケジューリングにおいて最高の優先順位を有するハ
イＱ（ＨＱ）を用いることが望ましい。また、前記スペ
シャルＩＯクラス２とスペシャルＩＯクラス３の作業Ｊ
ＯＢの場合に可能なかぎりスペシャル入出力部から装置
-装置に処理することが望ましい。また、前記ポリシー
記述表は、システムのリソースに対して４種のアプリケ
ーションのデフォルトリソース及び最大リソースの範囲
をポリシーとして記述することが望ましい。

【００１０】また、より望ましくは、前記ポリシー記述
表は入出力Ｉ／Ｏ作業ＪＯＢクラス１、２、３、及び４
に対して各クラスのアプリケーションが確保して用いる
ことができるＣＰＵ時間の最小値を所定の割合で最小リ
ソースを割り当てることによって各アプリケーションに
対するデフォルトリソースを割り当てる段階と、アプリ
ケーションの使用パターンによって４個のアプリケーシ
ョンクラスが共有できる残りリソースを割り当てる段階
と、各々のアプリケーションクラスに対して一定な範囲
のＣＰＵリソースを割り当てる段階とを含む方法によっ
て設定されたポリシーを含むことが望ましい。

【００１１】また、前記ポリシー記述表は新しいアプリ
ケーションが遂行される前に前記デフォルトリソース及
び最大リソースの範囲を用いてサービス品質ＱｏＳパラ
メータ交換とアドミッション制御を遂行する段階をさら
に含む方法によって設定されたポリシーを含むことが望
ましい。

【００１２】また、スペシャルＩＯクラス１の場合、
（ａ−１）ファイルバッファを割り当てる段階と、（ｂ
−１）Ｘを所定の正の整数とする時ファイルバッファか
らＸバイトを読み取る段階と、（ｃ−１）プロトコルデ
ータユニット（ＰＤＵ）でファイルバッファが空いてい
るかをチェックする段階と、（ｄ−１）前記（ｃ−１）
段階でファイルバッファが空いているとチェックされれ
ばフォーク（ｆｏｒｋ）を遂行してディスク装置をウェ
ークアップ（ｗａｋｅ−ｕｐ）して前記ディスク装置か
らデータを読み出す段階と、（ｅ−１）前記（ｄ−１）
段階の結果をハイＱ（ＨＱ）に貯蔵する段階と、（ｆ−
１）前記（ｃ−１）段階でファイルバッファが空いてい
ないとチェックされればハイＱ（ＨＱ）に貯蔵されてい
るデータを伝送して、ディスクをスリープ（ｓｌｅｅ
ｐ）状態に維持させる段階と、（ｇ−１）ＵＤＰデータ
をネットワーク装置に送る段階と、（ｈ−１）発送され
たＵＤＰデータをネットワーク装置側のバッファに貯蔵
する段階と、（ｉ−１）ネットワーク装置のバッファに
貯蔵されたＵＤＰデータを媒体アクセス制御によってネ
ットワーク装置に伝送する段階とを遂行して、前記スペ
シャルＩ／Ｏシステムコールは（ａ−１）ないし（ｆ−
１）段階に関与することが望ましい。

【００１３】また、スペシャルＩＯクラス２の場合、
（ａ−２）外部音声をマイクを通して入力する段階と、
（ｂ−２）入力された外部音声を電気的な音声信号に変
換する段階と、（ｃ−２）ハードウェアボコーダで変換
された音声信号をデジタル音声データに変換する段階
と、（ｄ−２）前記デジタル音声データをバッファに貯
蔵する段階と、（ｅ−２）バッファに貯蔵されたデジタ
ル音声データをパケット化する段階と、（ｆ−２）パケ
ット化されたデータをハイＱ（ＨＱ）に貯蔵する段階
と、（ｇ−２）パケット伝送要求信号であるＲＴＰ／ユ
ーザーデータパケットであるＵＤＰデータをネットワー
ク装置に送る段階と、（ｈ−２）発送されたＲＴＰ／Ｕ
ＤＰデータをネットワーク装置のバッファに貯蔵する段
階と、（ｉ−２）ネットワーク装置のバッファに貯蔵さ
れたＲＴＰ／ＵＤＰデータを媒体アクセス制御によって
ネットワーク装置に送る段階とを遂行して、前記スペシ
ャルＩ／Ｏシステムコールは（ｅ−２）ないし（ｇ−
２）段階に関与することが望ましい。

【００１４】また、前記パフォーマンス測定は、（ｐｍ
−ａ）各アプリケーションを複数のクラスに識別する段
階と、（ｐｍ−ｂ）アプリケーションのクラスに適合し
たテストプログラムを用いてパフォーマンスパラメータ
を測定する段階とを含んでなることが望ましい。

【００１５】また、前記（ｐｍ−ｂ）段階は、（ｐｍ−
ｂ−１）任務重大性（ｍｉｓｓｉｏｎ ｃｒｉｔｉｃａ
ｌ）作業はアプリケーション特性に合うベンチマークプ
ログラムを用いてどの程度のトランザクションを処理で
きるかを測定してシステムで処理しなければならない最
小及び最大トランザクションの数を決定する段階と、
（ｐｍ−ｂ−２）リソース予約を必要とするハイメディ
ア（ｈｉｇｈ ｍｅｄｉａ）アプリケーションとＧ．７
２３、及びＨ．２６３などの標準に従う対話形メディア
アプリケーションはスケジューリング周期等のようなサ
ービス品質ＱｏＳパラメータと、繰り返される重要ルー
チンに対する情報をユーザーが明示した次に、秒当たり
エンコーディングまたはデコーディング遂行時間を測定
する段階と、（ｐｍ−ｂ−３）その他リアルタイム処理
を要しないアプリケーションはパフォーマンス測定を省
略する段階とを含むことが望ましい。

【００１６】また、前記（ｐｍ−ｂ）段階は、（ｐｍ−
ｂ−１−ｎａ）もしも前記（ｐｍ−ｂ−１）段階で任務
重大性作業のみを遂行することにもシステムの性能が足
りないと決定されればより良い性能のシステムを用いる
ようにユーザーに表示する段階をさらに含むことが望ま
しい。

【００１７】また、前記他の課題を達成するために本発
明による運営体制カーネルは与えられたアプリケーショ
ンに対して入出力Ｉ／Ｏバウンド作業ＪＯＢパフォーマ
ンス及びＣＰＵバウンド作業ＪＯＢパフォーマンスを測
定することによってパフォーマンスパラメータを求め
て、ユーザーが予め設定したポリシーによってパフォー
マンスパラメータを適切に調整するための作業ＪＯＢア
ドミッション制御を遂行するエンタープライズＱｏＳリ
ソースマネージング手段と、前記パフォーマンス測定と
作業ＪＯＢアドミッション制御を基礎に、マルチメディ
アアプリケーションの特性上ユーザー空間へのデータ移
動が要らないデータに対して周期的に入出力作業ＪＯＢ
を遂行するようにスケジューリングするスペシャルＩ／
Ｏスケジューリング手段と、前記スペシャルＩ／Ｏスケ
ジューリング手段により決定された優先順位によってス
ペシャルＩ／Ｏシステムコールを遂行するスペシャルＩ
／Ｏサービスルーチン手段とを含むことを特徴とする。

【００１８】

【発明の実施の形態】以下、添付した図面を参照しなが
ら本発明をより詳しく説明する。図１には本発明による
マイクロスケジューリング方法が具現された運営体制カ
ーネルの構造をブロック図で示した。図１を参照する
と、本発明によるマイクロスケジューリング方法が具現
された運営体制カーネル１２はエンタープライズＱｏＳ
（Ｅ−ＱｏＳ）リソースマネジャー１２０、可用性テス
ト部１２２、アドミッション制御及びリソース予約部１
２４、ＣＰＵバウンドパフォーマンス測定部１２６、及
びＩＯバウンドパフォーマンス測定部１２８を備える。
また、運営体制カーネル１２はポリシー記述表１３０、
リソース予約プロトコル遂行部１３２、カーネルスケジ
ューラ１３４、スペシャルＩ／Ｏスケジューラ１３６、
スペシャルＩ／Ｏサービスルーチン１３８を備える。

【００１９】動作を説明すれば、エンタープライズＱｏ
Ｓ（Ｅ−ＱｏＳ）リソースマネジャー１２０はリソース
予約及びポリシー（ｐｏｌｉｃｙ）によるリソース割り
当てのためにＩ／ＯバウンドＪＯＢ及びＣＰＵバウンド
ＪＯＢに対するパフォーマンス測定を遂行して、ユーザ
ーが予め設定したポリシーによってパフォーマンスパラ
メータを適切に調整するためのＪＯＢアドミッション制
御を遂行する。

【００２０】また、示したようにエンタープライズＱｏ
Ｓ（Ｅ−ＱｏＳ）リソースマネジャー１２０は可用性テ
ストを遂行する可用性テスト部１２２、アドミッション
制御及びリソース予約を遂行するアドミッション制御及
びリソース予約部、ＣＰＵバウンドパフォーマンスに対
する測定を遂行するＣＰＵバウンドパフォーマンス測定
部１２６、ＩＯバウンドパフォーマンスに対する測定を
遂行するＩＯバウンドパフォーマンス測定部１２８と連
動されてリソースマネージングを遂行することと細分化
される場合もある。また、ポリシー記述表１３０には各
アプリケーション１０別システムリソースのデフォルト
範囲及び最大範囲が貯蔵されている。すなわち、前記エ
ンタープライズＱｏＳ（Ｅ−ＱｏＳ）リソースマネジャ
ー１２０はアプリケーション１０で予測したパフォーマ
ンスパラメータとアプリケーション１０クラスに従う優
先順位及びポリシー記述表からユーザーが設定したリソ
ース割り当てを基礎とするエンタープライズＱｏＳ（Ｅ
−ＱｏＳ）モデリングによってリソースマネージングを
遂行する。

【００２１】スペシャルＩ／Ｏスケジューラ１３６は前
記パフォーマンス測定とＪＯＢアドミッション制御を基
礎に、マルチメディアアプリケーションの特性上ユーザ
ー空間へのデータ移動が要らないデータに対して周期的
に入出力ＪＯＢを遂行するようにスケジューリングす
る。スペシャルＩ／Ｏサービスルーチン１３８は前記ス
ペシャルＩ／Ｏスケジューリング手段により決定された
優先順位によってスペシャルＩ／Ｏシステムコールを遂
行する。スペシャルＩ／Ｏサービスを遂行するシステム
コールはマルチメディアアプリケーションの特性上ユー
ザー空間へのデータ移動が要らない入出力動作を担当す
る。このような入出力動作は、例えば、ＤＶＤプレーヤ
ーでエンコーディングされているＭＰＥＧストリームを
ネットワークに発送するアプリケーションで現れる場合
がある。この場合、アプリケーションは作業の開始と終
了を担当して、中間にはモニターリングのみを遂行す
る。

【００２２】一般に、Ｉ／Ｏ ＪＯＢは次のような４種
のクラスに区分される。 １）Ｉ／Ｏサービスクラス１:ユーザー空間から装置に
データを移動させる。例えば、メモリ上のユーザーデー
タをコピーインしてディスクに貯蔵したりネットワーク
に伝送する場合がこれに該当する。 ２）Ｉ／Ｏサービスクラス２:ユーザー空間からユーザ
ー空間にデータを移動させる。例えば、ＴＣＰ（Ｔｒａ
ｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏ
ｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）プ
ロトコルによってローカルホストにデータを送る場合と
リップシンク（ｌｉｐ ｓｙｎｃ）のようなマルチメデ
ィアアプリケーション間でＩ／Ｏメカニズムを用いてデ
ータをやり取りする場合とがこれに該当する。

【００２３】３）Ｉ／Ｏサービスクラス３:装置からユ
ーザー空間にデータをやり取りする。例えば、ネットワ
ークから受信されたメッセージやディスクから読んだデ
ータをアプリケーションのデータ領域にコピーアウトす
る場合がこれに該当する。 ４）Ｉ／Ｏサービスクラス４:装置から装置にデータを
移動させる。例えば、ＣＤ−ＲＯＭのような貯蔵媒体に
ファイル形態に貯蔵されているデータをネットワークを
通して伝送したりネットワークファイルシステムに遠隔
システムがデータをアクセスする場合がこれに該当す
る。

【００２４】ここで、Ｉ／Ｏサービスクラス４がマルチ
メディアアプリケーションに現れる場合があるスペシャ
ルＩ／Ｏに該当する。スペシャルＩ／Ｏ（ＳＩＯ）は次
のような３種のクラスに区分される。 １）ＳＩＯクラス１:ディスクファイルからネットワー
クにまたはネットワークからディスクファイルに入出力
を遂行する。例えば、ＶＯＤ、ウェブダウンロード、Ｆ
ＴＰなどがこれに該当する。 ２）ＳＩＯクラス２:Ｉ／Ｏからネットワークにまたは
ネットワークからＩ／Ｏに入出力を遂行する。例えば、
ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐ
ｒｏｔｏｃｏｌ）、画像会議（ｖｉｄｅｏ ｃｏｎｆｅ
ｒｅｎｃｉｎｇ）等がこれに該当する。 ３）ＳＩＯクラス３:アプリケーションから／に入出力
を遂行する。またはスレッドからスレッドにまたはルー
プバック形態に入出力を遂行する。例えば、リップシン
クがこれに該当する。

【００２５】図２にはＳＩＯクラス１の構成例を示し
た。図２を参照すると、ＳＩＯクラス１の場合には、ま
ず、ファイルバッファを割り当てる。次には、ファイル
バッファから任意のＸバイトを読み取る。プロトコルデ
ータユニット（ＰＤＵ）側ではファイルバッファが空い
ているかをチェックして、その結果がファイルバッファ
が空いていることとチェックされればフォーク（ｆｏｒ
ｋ）を遂行してディスク装置をウェークアップ（ｗａｋ
ｅ−ｕｐ）して前記ディスク装置からデータを読んでそ
の結果をＨＱに貯蔵する。もしも、ファイルバッファが
空いていないとチェックされればＨＱに貯蔵されている
データを伝送して、ディスクをスリープ（ｓｌｅｅｐ）
状態に維持させる。データはユーザーデータプロトコル
（ｕｓｅｒｄａｔａ ｐｒｏｔｏｃｏｌ：ＵＤＰ）によ
ってネットワーク装置に発送し、発送されたデータはネ
ットワーク装置側のバッファに貯蔵される。ネットワー
ク装置のバッファに貯蔵されたＵＤＰデータは媒体アク
セス制御によってネットワーク装置に伝送される。ここ
で、スペシャルＩ／Ｏ（ＳＩＯ）システムコールは点線
で示したように、ファイルバッファ割り当てでディスク
読出し及びスリープ状態／ウェークアップ状態維持まで
を関与する。

【００２６】図３にはＳＩＯクラス２の構成例を示し
た。図３を参照すると、ＳＩＯクラス２の場合にはま
ず、外部音声がマイクに入力されて電気的な音声信号に
変換される。変換された音声信号はハードウェアボコー
ダに入力されてデジタル音声データに変換される。デジ
タル音声データはバッファに貯蔵されてからパケット化
される。パケット化されたデータはＨＱに貯蔵される。
次に、リアルタイム伝送プロトコル（ｒｅａｌ−ｔｉｍ
ｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ：以下ＲＴＰ
と称する）／ユーザーデータプロトコル（以下ＵＤＰと
称する）によってパケット化されたデータがネットワー
ク装置に発送される。ＲＴＰ／ＵＤＰによって発送され
たデータはネットワーク装置のバッファに貯蔵される。
ネットワーク装置のバッファに貯蔵されたデータは媒体
アクセス制御によってネットワーク装置に伝送される。
ここで、スペシャルＩ／Ｏ（ＳＩＯ）システムコールは
点線で示したようにバッファへの貯蔵からＲＴＰ／ＵＤ
Ｐ発送まで関与する。

【００２７】図４にはＳＩＯクラス３の構成例を示し
た。図４を参照すると、ＳＩＯクラス３の場合にはま
ず、マイクを通して入力された外部音声は電気的な音声
信号に変換される。変換された電気的な音声信号はデジ
タル音声データに変換されてバッファに貯蔵される。バ
ッファに貯蔵された音声データはソフトウェアボコーダ
に入力される。ソフトウェアボコーダは音声データをパ
ケット化してＨＱに貯蔵する。以後の動作は図３を参照
して説明したことと同一である。

【００２８】一方、エンタープライズＱｏＳ（Ｅ−Ｑｏ
Ｓ）リソースマネジャー１２０は一定な類型のＪＯＢに
対するパフォーマンス測定とユーザーが予め設定したポ
リシー（ｐｏｌｉｃｙ）によってＪＯＢアドミッション
制御を遂行する。パフォーマンス測定は１２．５マイク
ロ秒を一つのＰＵ（ｐｅｒｆｏｒｍａｎｃｅ ｕｎｉ
ｔ：パフォーマンスユニット）にする。すなわち、ある
アプリケーションが遂行される時間をいくつのＰＵを必
要としているかを計算して決定する。

【００２９】大部分のペンティアム（登録商標）級シス
テムではフォーク（ｆｏｒｋ）や実行動作（ｅｘｅｃ）
を除いて大部分のシステムコールが数マイクロ秒から数
十マイクロ秒以内に遂行されて、通信ネットワークにお
ける基本フレーム単位が１２．５マイクロ秒であるか
ら、ＰＵは１２．５マイクロ秒であることが望ましい。
また、ＰＵを１２．５マイクロ秒に設定すれば、今後マ
ルチメディアアプリケーションに対するパフォーマンス
測定及びベンチマーキングに容易に適用できるという長
所がある。このような場合、可用パフォーマンスとして
６４０ミリ秒は５１、２００ＰＵに該当する。しかし、
ＰＵ設定は１２．５マイクロ秒に限らずシステムの性能
によって可変できる。

【００３０】また、例えば、システムやネットワークで
ＭＰＥＧストリームを処理する場合、秒当たり３０ない
し６０フレームが伝送されるべきで、Ｇ．７２３標準に
よって音声通話を遂行する場合には３０ミリ秒単位に音
声パケットが伝送されるべきである。この場合、ＣＰＵ
が処理可能なＭＩＰＳ値よりはメモリコピー（ｃｏｐ
ｙ）の性能と深い関係があるシステムバスの速度、通信
プロトコル、Ｉ／Ｏバッファ大きさなどがシステムの性
能を左右する。

【００３１】すなわち、一般的なマルチメディアシステ
ムでタイムインターバル（ｔｉｍｅｉｎｔｅｒｖａｌ）
はＱｏＳパラメータにおいて最も重要な属性であるか
ら、本実施の形態でシステムの性能をＭＩＰＳ単位では
なくてタイムインターバルを用いて、また、このような
タイムインターバルをスケジューリングの基準として用
いるために効率的にマルチメディアデータを処理でき
る。しかし、ＭＰＥＧデコーディングのようなＣＰＵバ
ウンドＪＯＢの場合にはＣＰＵのＭＩＰＳが重要な尺度
になる。すなわち、アプリケーションのクラスによって
パフォーマンス測定の単位が変わる場合がある。

【００３２】したがって、各アプリケーションに対する
パフォーマンス測定はアプリケーションのクラスによっ
てテストプログラムに基本的な数値を定めた次に、実際
運用環境で測定値を補正する。 １）任務重大性作業はテビット−クレジット（ｄｅｂｉ
ｔ−ｃｒｅｄｉｔ）のようなアプリケーション特性に合
うベンチマークプログラムを用いてどの程度のトランザ
クションを処理できるかを測定する。システムで処理し
なければならない最小及び最大トランザクションの数を
決定するべきで、もしも、このような作業のみを遂行す
ることにもシステムの性能が足りないと決定されればよ
り良い性能のシステムを用いるようにユーザーに表示し
なければならない。

【００３３】２）リソース予約を必要とするハイメディ
アアプリケーションとＧ．７２３、及びＨ．２６３など
の標準に従う対話形メディアアプリケーションはスケジ
ューリング周期等のようなＱｏＳパラメータと、繰り返
される重要ルーチンに対する情報をユーザーが明示した
次に、秒当たりエンコーディングまたはデコーディング
遂行時間を測定する。 ３）その他リアルタイム処理を要しないアプリケーショ
ンはパフォーマンス測定を遂行しないことによってパフ
ォーマンス測定によって生じる場合があるオーバヘッド
を減らす。しかし、アプリケーションはシステムのパフ
ォーマンスに対する情報を入手して対応することが可能
で、ユーザーに予測応答時間を知らせることが望まし
い。

【００３４】一方、ポリシー設定はシステムのリソース
に対して４種のアプリケーションのデフォルト及び最大
範囲を決定する。次には新しいアプリケーションが遂行
される前に前記デフォルト及び最大範囲を基礎にＱｏＳ
パラメータ交換を遂行した次に、アドミッション制御を
遂行する。ポリシー設定は例えば次のように遂行するこ
とができる。

【００３５】１）全体システムに対して各クラスのアプ
リケーションが確保して用いることができるＣＰＵ時間
の最小値を決定する。全体システムのＰＵ（ＰＵ＿ｓｙ
ｓ）＝５１、２００ＰＵでＩ／Ｏ ＪＯＢに対するリソ
ース分配を２０、０００ＰＵとして、残りはユーザープ
ロセスのＣＰＵバウンドＪＯＢを遂行させようとする場
合、Ｉ／Ｏ ＪＯＢクラス１、２、３、及び４に対して
各々２０％、１０％、１０％、１０％に最小リソースを
割り当てるならば、各アプリケーションに対する最小リ
ソースは、 ＰＵｃ１＿ｄｅｆ（クラス１のアプリケーションに対す
るデフォルトＰＵ）＝４、０００ＰＵ ＰＵｃ２＿ｄｅｆ（クラス２のアプリケーションに対す
るデフォルトＰＵ）＝２、０００ＰＵ ＰＵｃ３＿ｄｅｆ（クラス３のアプリケーションに対す
るデフォルトＰＵ）＝２、０００ＰＵ ＰＵｃ４＿ｄｅｆ（クラス４のアプリケーションに対す
るデフォルトＰＵ）＝２、０００ＰＵのように割り当て
られる。

【００３６】２）次には、アプリケーションの使用パタ
ーンによって残りリソースを割り当てる。全体２０、０
００ＰＵから１０、０００ＰＵをデフォルトに割り当て
たので、残った可用リソースは１０、０００ＰＵであ
る。この残りリソースは４個のアプリケーションクラス
が共有できるリソースである。もしも、クラス１のアプ
リケーションの使用パターンで最大使用値を大きくし、
クラス３は定まった値以上を超過できないようにしよう
とするならば、付加的なリソースは、 ＰＵｃ１＿ａｄｄ（クラス１のアプリケーションに対す
る付加ＰＵ）＝７、５００ＰＵ ＰＵｃ２＿ａｄｄ（クラス２のアプリケーションに対す
る付加ＰＵ）＝２、５００ＰＵ ＰＵｃ３＿ａｄｄ（クラス３のアプリケーションに対す
る付加ＰＵ）＝０ＰＵ ＰＵｃ４＿ａｄｄ（クラス４のアプリケーションに対す
る付加ＰＵ）＝７、５００ＰＵのように配分されること
ができる。

【００３７】したがって、各々のアプリケーションクラ
スは、 ＰＵｃ１＝＜ＰＵｃ１＿ｄｅｆ、ＰＵｃ１＿ｍａｘ＞＝
＜４、０００、１１、５００＞ＰＵ ＰＵｃ２＝＜ＰＵｃ２＿ｄｅｆ、ＰＵｃ２＿ｍａｘ＞＝
＜２、０００、４、５００＞ＰＵ ＰＵｃ３＝＜ＰＵｃ３＿ｄｅｆ、ＰＵｃ３＿ｍａｘ＞＝
＜２、０００、２、０００＞ＰＵ ＰＵｃ４＝＜ＰＵｃ４＿ｄｅｆ、ＰＵｃ４＿ｍａｘ＞＝
＜２、０００、９、５００＞ＰＵのような範囲のＣＰＵ
リソースを割り当てられるようになる。

【００３８】エンタープライズＱｏＳ（Ｅ−ＱｏＳ）モ
デリングは与えられたアプリケーションに対して測定さ
れたパフォーマンスパラメータとアプリケーションクラ
スとに従う優先順位及びポリシー管理者でユーザーが設
定したリソース割り当てを基礎として次のように遂行さ
れる。ここで、スケジューリングに用いられるタスクＱ
はクラス１のアプリケーションに関連したＭＱ、クラス
２及び３のアプリケーションに関連したＨＱとクラス４
のアプリケーションに関連したＬＱの３種に区分され
る。

【００３９】まず、アプリケーションのクラスによるパ
フォーマンスパラメータを説明すると次の通りである。
クラス２のアプリケーションの代表的な例としては音声
通信と画像会議がある。音声通信の場合、片方方向の処
理を見れば、二段階のタスクに区分できる。最初はＩ／
Ｏ装置で音声コーデックを通してデータを読んで、二回
目は通信プロトコルを用いて前記データをパケット形態
に３０ミリ秒間隔に伝送することである。画像会議の場
合には各々ボコーダとビデオコーダーを通して入力され
たデータを、音声は３０ミリ秒単位に映像は３０ないし
１５０ミリ秒単位に伝送する。クラス３のアプリケーシ
ョンはシステムリソースをヘビー（ｈｅａｖｙ）に用い
るという点を除いてはクラス２のアプリケーションと同
一な性格を有する。クラス２とクラス３のアプリケーシ
ョンは一般に１０ミリ秒単位のスケジューリングを要
し、このようなＪＯＢが多い場合には既存のシステムで
はコンテキストオーバヘッド（ｃｏｎｔｅｘｔ ｏｖｅ
ｒｈｅａｄ）によって効率的なシステムを設計できなか
った。

【００４０】本発明によるＥ−ＱｏＳモデルではクラス
２とクラス３のアプリケーションは可能なかぎりスペシ
ャルＩ／Ｏから装置-装置に処理する。したがって、ユ
ーザー空間のコンテキストスイッチングが最少化され
る。また、このようにする場合にはＪＯＢの遂行時間、
すなわち、ＰＵの予測が容易である。また、本発明の実
施の形態によるとクラス２とクラス３のＪＯＢはスケジ
ューリングにおいて最高の優先順位を有するＨＱを用い
る。ＨＱはタイムインターバルを有することができる構
造を有して、スケジューラはこのタイムインターバルと
ＪＯＢの遂行時間にしたがってＪＯＢを均等に配分す
る。

【００４１】図５にはＨＱのＪＯＢインターバル分布の
一例を示した。図５を参照すると、１０ミリ秒では２０
０ＰＵがＩ／Ｏに割り当てられる。クラス２のアプリケ
ーションは＜２０、４５＞、クラス３のアプリケーショ
ンは＜２０、２０＞の範囲に該当するＰＵを配分する。
また、クラス１とクラス４のアプリケーションに対する
ＰＵのデフォルト値を合せた６０ＰＵは予備に残してお
く。ここで、クラス２とクラス３の最大ＰＵとクラス１
及びクラス４のデフォルトＰＵ合算値が２００を超過す
る場合には一部クラス２及びクラス３のＪＯＢに対する
ＱｏＳを保障できなくなる。したがって、本発明の実施
の形態によると、アドミッション制御においてクラス２
とクラス３の最大ＰＵとクラス１及びクラス４のデフォ
ルトＰＵ合算値が２００を超過する場合には適切に制御
する。

【００４２】本発明の実施の形態によると、ＨＱをＪＯ
Ｂスケジューリングに必要なタイム周期の最大公約数
（ｇｒｅａｔｅｓｔｃｏｍｍｏｎｄｅｖｉｓｏｒ：以下
ＧＣＤと称する）を単位で構成する。１０ミリ秒以下の
場合は１０ミリ秒と見做すことが望ましい。また、毎Ｇ
ＣＤ周期ごとに該ＱにあるＪＯＢを消尽される時まで順
次的に処理する。

【００４３】図６にはＨＱの構成の一例を示した。図６
を参照すると、７個のクラス２及びクラス３のＪＯＢが
ＨＱに分布される。クラス１のアプリケーションのトラ
ンザクションはハードリアルタイムを要しないために定
まったＰＵを適切に配分して用いればよい。クラス１の
スケジューリングは環状伝送（ＲＲ：ｒｏｕｎｄ ｒｏ
ｂｉｎ）を用いる。クラス４のアプリケーションは優先
順位が最も低く、クラス１と同一に環状伝送を用いてス
ケジューリングを遂行する。ＨＱに貯蔵された作業を遂
行した次に、ＭＱに貯蔵されたクラス１のＪＯＢを遂行
して、ＬＱに貯蔵されたクラス４のＪＯＢを遂行する。
しかし、クラス１のアプリケーションは別途のＱ、すな
わち、ＭＱを有するが、ＨＱでＭＱのデフォルト部分を
常に予備しているために一定なリソースに対しては優先
順位を保障できる。

【００４４】Ｉ／Ｏ装置からネットワークにデータを移
動させる場合は２種の形態がある。一つはＩ／Ｏバッフ
ァからネットワークバッファにデータを移動させる場合
であり、他の一つはディスクからデータを読んでネット
ワークに伝送する場合である。Ｉ／Ｏバッファからネッ
トワークバッファにデータを伝送する場合は前述したＳ
ＩＯクラス２に該当して、例えば、ＶｏＩＰ、画像会議
などがこれに該当する。ＶｏＩＰアプリケーションでは
初期にＴＣＰを用いてコール設定をして、次にマイク／
ボコーダ装置を通して入力されるパケットをＴＵＰ／Ｕ
ＤＰを通してネットワークに伝送するようになる。この
際、実際データは毎３０ミリ秒単位に３０バイト程度の
データをネットワークに発送しなければならない。アプ
リケーションはスリープ（ｓｌｅｅｐ）状態に入り込ん
で、ＲＴＰセッションのモニターリング事象発生時にこ
れの処理のみを遂行すればよい。したがって、カーネル
空間からユーザー空間にデータコピーインまたはコピー
アウトを要せず、これを遂行するためのＶｏＩＰユーザ
ープロセスをスケジューリングする必要もない。

【００４５】このような本発明による方法によると、周
期的なスケジューリングが可能ながらもシステムのオー
バヘッドは劇的に省くことができる。ディスクからＭＰ
ＥＧストリームのようなファイルデータを読んでネット
ワークに伝送する場合はＶＯＤのようなアプリケーショ
ンやＨＴＭＬ文書からも見ることができる。このような
アプリケーションではファイルをオープンした後にデー
タをユーザー空間のバッファに読み取る。次にはＵＤＰ
データパケットを作ってネットワークに伝送する。

【００４６】図７にはディスクＩＯを伴ったスペシャル
Ｉ／Ｏ ＪＯＢを一例として説明するための図面を示し
た。図７を参照すると、カーネル内にディスクリードを
伴うスペシャルＩ／Ｏ（ＳＩＯ）システムコールを処理
する過程が示されている。ＭＰＥＧ２ストリームを秒当
たり３０フレーム、５００キロバイト／フレームに伝送
しなければならない場合にはスペシャルＩ／Ｏルーチン
は３個の事象によって処理される。まず、ファイルバッ
ファにデータがある場合には直ちにパケットを構成して
ＵＤＰデータとして伝送する。しかし、ファイルバッフ
ァに次に伝送するデータがない場合には直ちにディスク
から読み取るルーチンを呼び出す。ディスクＩ／Ｏは２
０ミリ秒程度所要されるのでディスクインタラプトが生
じればこれを応答してデータをファイルバッファに用い
る。

【００４７】前記のような本発明による運営体制はエン
タープライズＱｏＳ（Ｅ−ＱｏＳ）モデルでマイクロス
ケジューリングアルゴリズムを用いることによって任務
重大性アプリケーションと対話形マルチメディアまたは
ＭＰＥＧビデオプレーのようなマルチメディアアプリケ
ーションをクラスで区分してクラス別にシステム及びネ
ットワークリソースを割り当てて調整することによって
専用サービス網でないイントラネット及びインターネッ
トでマルチメディアＱｏＳを効率性良く支援できる。

【００４８】前記のような本発明によるマイクロスケジ
ューリング方法はマルチメディアデータを処理する運営
体制が存在する全てのコンピュータと、ウェブサーバ
ー、マルチメディアサーバー等のようなサーバー（ｓｅ
ｒｖｅｒ）と、ラウタ（ｒｏｕｔｅｒ）のようなネット
ワーク装備、及びコンピュータスイッチング装備等の運
営体制に適用できる。

【００４９】特に、前記のような本発明によるマイクロ
スケジューリングアルゴリズムはコンピュータプログラ
ムで作成することができる。前記プログラムはマルチメ
ディアアプリケーションを支援するための運営体制カー
ネル内に挿入されることによって運営体制カーネルとし
て具現できる。前記プログラムはコード及びコードセグ
メントを含んで本発明が属する技術分野のプログラマー
により容易に推論できる。そして、コンピュータで用い
られる媒体から前記プログラムを動作させる汎用ディジ
タルコンピューターで具現できる。このようなプログラ
ムはコンピュータで読むことができる記録媒体に貯蔵さ
れることができる。前記記録媒体はフロッピー（登録商
標）ディスクやハードディスクのような磁気記録媒体
と、ＣＤ−ＲＯＭやＤＶＤのような光記録媒体を含む。
また、前記プログラムはインターネットのような搬送波
によって伝送できる。

【００５０】

【発明の効果】上述したように本発明によるとマルチメ
ディアデータを処理する運営体制が存在する全てのコン
ピュータと、ウェブサーバー、マルチメディアサーバー
等のようなサーバーと、ラウタのようなネットワーク装
備、及びコンピュータスイッチング装備等の運営体制に
システムコールを追加的に用いることによってマルチメ
ディアＱｏＳを効率性良く支援できる。

【図面の簡単な説明】

【図１】 本発明によるマイクロスケジューリング方法
が具現された運営体制カーネルの構造を示したブロック
図である。

【図２】 スペシャルＩＯクラス１の構成例を示した図
面である。

【図３】 スペシャルＩＯクラス２の構成例を示した図
面である。

【図４】 スペシャルＩＯクラス３の構成例を示した図
面である。

【図５】 ハイＱ（ＨＱ）のＪＯＢインターバル分布の
一例を示した図面である。

【図６】 ハイＱ（ＨＱ）の構成の一例を示したブロッ
ク図である。

【図７】 ディスクＩＯを伴ったスペシャルＩ／Ｏ作業
（ＪＯＢ）を説明するための図面である。

【符号の説明】

１０：アプリケーション １２：運営体制カーネル １２０：エンタープライズＱｏＳ（Ｅ−ＱｏＳ）リソー
スマネジャー １２２：可用性テスト部 １２４：アドミッション制御及びリソース予約部 １２６：ＣＰＵバウンドパフォーマンス測定部 １２８：ＩＯバウンドパフォーマンス測定部 １３０：ポリシー記述表 １３２：リソース予約プロトコル遂行部 １３４：カーネルスケジューラ １３６：スペシャルＩ／Ｏスケジューラ １３８：スペシャルＩ／Ｏサービスルーチン

Claims (34)

【特許請求の範囲】
1. 【請求項１】 マルチメディアアプリケーションを支援
   するための運営体制カーネルで具現されるスケジューリ
   ング方法において、 （ａ）与えられたアプリケーションに対して入出力バウ
   ンド作業パフォーマンス及びＣＰＵバウンド作業パフォ
   ーマンスを測定することによってパフォーマンスパラメ
   ータを求める段階と、 （ｂ）システム管理者が作業アドミッション制御を遂行
   することによって予め設定したポリシーによってパフォ
   ーマンスパラメータを適切に調整する段階と、 （ｃ）前記パフォーマンス測定と作業アドミッション制
   御を基礎に、マルチメディアアプリケーションの特性上
   ユーザー空間へのデータ移動が要らないデータに対して
   周期的に入出力作業を遂行するようにスケジューリング
   して、アプリケーションクラスに対する処理の優先順位
   を決定する段階と、 （ｄ）前記（ｃ）段階により決定された優先順位によっ
   てスペシャルＩ／Ｏシステムコールを遂行する段階とを
   含むことを特徴とするマイクロスケジューリング方法。
2. 【請求項２】 前記（ａ）段階は、アプリケーションの
   クラスに適合したテストプログラムを用いて与えられた
   アプリケーションに対して入出力バウンド作業パフォー
   マンス及びＣＰＵバウンド作業パフォーマンスを測定す
   ることによってパフォーマンスパラメータを求めること
   を特徴とする請求項１に記載のマイクロスケジューリン
   グ方法。
3. 【請求項３】 前記（ｂ）段階は、 前記（ａ）段階で求めたパフォーマンスパラメータとア
   プリケーションクラスとに対する処理の優先順位及びポ
   リシー記述表からシステム管理者が設定したリソース割
   り当てを基礎とするエンタープライズサービス品質モデ
   リングにより遂行されることを特徴とする請求項１に記
   載のマイクロスケジューリング方法。
4. 【請求項４】 可用性テストを遂行する段階と、 アドミッション制御及びリソース予約を遂行する段階
   と、 システムリソースに対して各アプリケーション別デフォ
   ルト及び最大範囲を決定するためのポリシーを記述する
   段階と、 ＣＰＵバウンドパフォーマンスに対する測定を遂行する
   段階と、 入出力バウンドパフォーマンスに対する測定を遂行する
   段階をさらに含むことを特徴とする請求項１に記載のマ
   イクロスケジューリング方法。
5. 【請求項５】 前記スペシャルＩ／Ｏシステムコール
   は、 ユーザー空間から装置にデータを移動させる入出力サー
   ビスクラス１、ユーザー空間からユーザー空間にデータ
   を移動させる入出力サービスクラス２、ユーザー空間に
   データをやり取りする入出力サービスクラス３、及び装
   置から装置にデータを移動させる入出力サービスクラス
   ４の４種のクラスに区分される入出力作業において、 マルチメディアアプリケーションに現れる場合がある入
   出力サービスクラス４をスペシャルＩ／Ｏに該当する作
   業であると決定して、アプリケーションで遂行する作業
   がスペシャルＩ／Ｏに該当する場合に前記スペシャルＩ
   ／Ｏスケジューリング手段により配分されたリソースに
   よって周期的な入出力を担当することを特徴とする請求
   項１ないし４のうちいずれか一に記載のマイクロスケジ
   ューリング方法。
6. 【請求項６】 前記スペシャルＩＯは、 ディスクファイルからネットワークにまたはネットワー
   クからディスクファイルに入出力を遂行するスペシャル
   ＩＯクラス１、入出力部からネットワークにまたはネッ
   トワークから入出力部に入出力を遂行するスペシャルＩ
   Ｏクラス２、及びアプリケーションから／に入出力を遂
   行したりスレッドからスレッドにまたはループバック形
   態で入出力を遂行するスペシャルＩＯクラス３の３種の
   クラスに区分されることを特徴とする請求項５に記載の
   マイクロスケジューリング方法。
7. 【請求項７】 前記（ｃ）段階でスケジューリングに用
   いられるタスクＱは、 スペシャルＩＯクラス１のアプリケーションに関連した
   ミディアムＱ、スペシャルＩＯクラス２及び３のアプリ
   ケーションに関連したハイＱとスペシャルＩＯクラス４
   のアプリケーションに関連したローＱの３種に区分され
   ることを特徴とする請求項６に記載のマイクロスケジュ
   ーリング方法。
8. 【請求項８】 前記（ｃ）段階は、 前記スペシャルＩＯクラス２とスペシャルＩＯクラス３
   のＪＯＢの場合にスケジューリングにおいて最高の優先
   順位を有するハイＱを用いることを特徴とする請求項７
   に記載のマイクロスケジューリング方法。
9. 【請求項９】 前記スペシャルＩＯクラス２とスペシャ
   ルＩＯクラス３の作業の場合に可能なかぎりスペシャル
   入出力部から装置-装置に処理することを特徴とする請
   求項７に記載のマイクロスケジューリング方法。
10. 【請求項１０】 前記ポリシー記述表は、 システムのリソースに対して４種のアプリケーションの
    デフォルトリソース及び最大リソースの範囲をポリシー
    として記述することを特徴とする請求項２に記載のマイ
    クロスケジューリング方法。
11. 【請求項１１】 前記ポリシー記述表は、 入出力作業クラス１、２、３、及び４に対して各クラス
    のアプリケーションが確保して用いることができるＣＰ
    Ｕ時間の最小値を所定の割合で最小リソースを割り当て
    ることによって各アプリケーションに対するデフォルト
    リソースを割り当てる段階と、 アプリケーションの使用パターンによって４個のアプリ
    ケーションクラスが共有できる残りリソースを割り当て
    る段階と、 各々のアプリケーションクラスに対して一定な範囲のＣ
    ＰＵリソースを割り当てる段階とを含む方法により設定
    されたポリシーを含むことを特徴とする請求項１０に記
    載のマイクロスケジューリング方法。
12. 【請求項１２】 新しいアプリケーションが遂行される
    前に前記デフォルトリソース及び最大リソースの範囲を
    用いてサービス品質パラメータ交換とアドミッション制
    御とを遂行することを特徴とする請求項１１に記載のマ
    イクロスケジューリング方法。
13. 【請求項１３】 スペシャルＩＯクラス１の場合、 （ａ−１）ファイルバッファを割り当てる段階と、 （ｂ−１）Ｘを所定の正の整数とする時ファイルバッフ
    ァからＸバイトを読み取る段階と、 （ｃ−１）プロトコルデータユニットでファイルバッフ
    ァが空いているかをチェックする段階と、 （ｄ−１）前記（ｃ−１）段階でファイルバッファが空
    いているとチェックされればフォークを遂行してディス
    ク装置をウェークアップして前記ディスク装置からデー
    タを読み出す段階と、 （ｅ−１）前記（ｄ−１）段階の結果をハイＱに貯蔵す
    る段階と、 （ｆ−１）前記（ｃ−１）段階でファイルバッファが空
    いていないとチェックされればハイＱに貯蔵されている
    データを伝送して、ディスクをスリープ状態に維持させ
    る段階と、 （ｇ−１）ＵＤＰデータをネットワーク装置に送る段階
    と、 （ｈ−１）発送されたＵＤＰデータをネットワーク装置
    側のバッファに貯蔵する段階と、 （ｉ−１）ネットワーク装置のバッファに貯蔵されたＵ
    ＤＰデータを媒体アクセス制御によってネットワーク装
    置に伝送する段階とを遂行して、 前記スペシャルＩ／Ｏシステムコールは（ａ−１）ない
    し（ｆ−１）段階に関与することを特徴とする請求項６
    に記載のマイクロスケジューリング方法。
14. 【請求項１４】 スペシャルＩＯクラス２の場合、 （ａ−２）外部音声をマイクを通して入力する段階と、 （ｂ−２）入力された外部音声を電気的な音声信号に変
    換する段階と、 （ｃ−２）ハードウェアボコーダから変換された音声信
    号をデジタル音声データに変換する段階と、 （ｄ−２）前記デジタル音声データをバッファに貯蔵す
    る段階と、 （ｅ−２）バッファに貯蔵されたデジタル音声データを
    パケット化する段階と、 （ｆ−２）パケット化されたデータをハイＱに貯蔵する
    段階と、 （ｇ−２）パケット伝送要求信号であるＲＴＰ／ユーザ
    ーデータパケットであるＵＤＰデータをネットワーク装
    置に送る段階と、 （ｈ−２）発送されたＲＴＰ／ＵＤＰデータをネットワ
    ーク装置のバッファに貯蔵する段階と、 （ｉ−２）ネットワーク装置のバッファに貯蔵されたＲ
    ＴＰ／ＵＤＰデータを媒体アクセス制御によってネット
    ワーク装置に送る段階とを遂行して、 前記スペシャルＩ／Ｏシステムコールは（ｅ−２）ない
    し（ｇ−２）段階に関与することを特徴とする請求項６
    に記載のマイクロスケジューリング方法。
15. 【請求項１５】 前記パフォーマンス測定は、 （ｐｍ−ａ）各アプリケーションを複数のクラスに識別
    する段階と、 （ｐｍ−ｂ）アプリケーションのクラスに適合したテス
    トプログラムを用いてパフォーマンスパラメータを測定
    する段階とを含んでなることを特徴とする請求項１に記
    載のマイクロスケジューリング方法。
16. 【請求項１６】 前記（ｐｍ−ｂ）段階は、 （ｐｍ−ｂ−１）任務重大性作業はアプリケーション特
    性に合うベンチマークプログラムを用いてどの程度のト
    ランザクションを処理できるかを測定してシステムで処
    理しなければならない最小及び最大トランザクションの
    数を決定する段階と、 （ｐｍ−ｂ−２）リソース予約を必要とするハイメディ
    アアプリケーションとＧ．７２３、及びＨ．２６３など
    の標準に従う対話形メディアアプリケーションはスケジ
    ューリング周期等のようなサービス品質パラメータと、
    繰り返される重要ルーチンに対する情報をユーザーが明
    示した次に、秒当たりエンコーディングまたはデコーデ
    ィング遂行時間を測定する段階と、 （ｐｍ−ｂ−３）その他リアルタイム処理を要しないア
    プリケーションはパフォーマンス測定を省略する段階と
    を含むことを特徴とする請求項１５に記載のマイクロス
    ケジューリング方法。
17. 【請求項１７】 前記（ｐｍ−ｂ）段階は、 （ｐｍ−ｂ−１−ｎａ）もしも前記（ｐｍ−ｂ−１）段
    階で任務重大性作業のみを遂行することにもシステムの
    性能が足りないと決定されればより良い性能のシステム
    を用いるようにユーザーに表示する段階をさらに含むこ
    とを特徴とする請求項１６に記載のマイクロスケジュー
    リング方法。
18. 【請求項１８】 マルチメディアアプリケーションを支
    援するための運営体制カーネルにおいて、 与えられたアプリケーションに対して入出力バウンド作
    業パフォーマンス及びＣＰＵバウンド作業パフォーマン
    スを測定することによってパフォーマンスパラメータを
    求めて、ユーザーが予め設定したポリシーによってパフ
    ォーマンスパラメータを適切に調整するための作業アド
    ミッション制御を遂行するエンタープライズＱｏＳリソ
    ースマネージング手段と、 前記パフォーマンス測定と作業アドミッション制御を基
    礎に、マルチメディアアプリケーションの特性上ユーザ
    ー空間へのデータ移動が要らないデータに対して周期的
    に入出力作業を遂行するようにスケジューリングするス
    ペシャルＩ／Ｏスケジューリング手段と、 前記スペシャルＩ／Ｏスケジューリング手段により決定
    された優先順位によってスペシャルＩ／Ｏシステムコー
    ルを遂行するスペシャルＩ／Ｏサービスルーチン手段と
    を含むことを特徴とする運営体制カーネル。
19. 【請求項１９】 前記エンタープライズＱｏＳリソース
    マネージング手段は、 与えられたアプリケーションに対して測定されたパフォ
    ーマンスパラメータとアプリケーションクラスとに従う
    優先順位及びポリシー記述表からユーザーが設定したリ
    ソース割り当てを基礎とするエンタープライズＱｏＳモ
    デリングによりリソースマネージングを遂行することを
    特徴とする請求項１８に記載の運営体制カーネル。
20. 【請求項２０】 前記各クラスのアプリケーションに対
    するパフォーマンス測定は、 アプリケーションのクラスに適合したテストプログラム
    を用いることを特徴とする請求項１８に記載の運営体制
    カーネル。
21. 【請求項２１】 可用性テストを遂行する可用性テスト
    手段と、 アドミッション制御及びリソース予約を遂行するアドミ
    ッション制御及びリソース予約手段と、 システムリソースに対して各アプリケーション別デフォ
    ルト及び最大範囲を決定するためのポリシー記述表と、 ＣＰＵバウンドパフォーマンスに対する測定を遂行する
    ＣＰＵバウンドパフォーマンス測定手段と、 入出力バウンドパフォーマンスに対する測定を遂行する
    ＩＯバウンドパフォーマンス測定手段をさらに含むこと
    を特徴とする請求項１８に記載の運営体制カーネル。
22. 【請求項２２】 前記スペシャルＩ／Ｏシステムコール
    は、 ユーザー空間から装置にデータを移動させるＩ／Ｏサー
    ビスクラス１、ユーザー空間からユーザー空間にデータ
    を移動させるＩ／Ｏサービスクラス２、ユーザー空間に
    データをやり取りするＩ／Ｏサービスクラス３、及び装
    置から装置にデータを移動させるＩ／Ｏサービスクラス
    ４の４種のクラスに区分されるＩ／Ｏ作業で、 マルチメディアアプリケーションに現れる場合のあるＩ
    ／Ｏサービスクラス４をスペシャルＩ／Ｏに該当するＪ
    ＯＢであると決定して、アプリケーションで遂行するＪ
    ＯＢがスペシャルＩ／Ｏに該当する場合に前記スペシャ
    ルＩ／Ｏスケジューリング手段により配分されたリソー
    スによって周期的な入出力を担当することを特徴とする
    請求項１８ないし２１のうちいずれか一に記載の運営体
    制カーネル。
23. 【請求項２３】 前記スペシャルＩ／Ｏは、 ディスクファイルからネットワークにまたはネットワー
    クからディスクファイルに入出力を遂行するスペシャル
    ＩＯクラス１、Ｉ／Ｏからネットワークにまたはネット
    ワークからＩ／Ｏに入出力を遂行するスペシャルＩＯク
    ラス２、及びアプリケーションから／に入出力を遂行し
    たりスレッドからスレッドにまたはループバック形態で
    入出力を遂行するスペシャルＩＯクラス３の３種のクラ
    スに区分されることを特徴とする請求項２２に記載の運
    営体制カーネル。
24. 【請求項２４】 前記スペシャルＩ／Ｏスケジューリン
    グ手段でスケジューリングに用いられるタスクＱは、 スペシャルＩＯクラス１のアプリケーションに関連した
    ミディアムＱ、スペシャルＩＯクラス２及び３のアプリ
    ケーションに関連したハイＱとスペシャルＩＯクラス４
    のアプリケーションに関連したローＱの３種に区分され
    ることを特徴とする請求項２３に記載の運営体制カーネ
    ル。
25. 【請求項２５】 前記スペシャルＩ／Ｏスケジューリン
    グ手段は、 前記スペシャルＩＯクラス２とスペシャルＩＯクラス３
    のＪＯＢの場合にスケジューリングにおいて最高の優先
    順位を有するハイＱを用いることを特徴とする請求項２
    ４に記載の運営体制カーネル。
26. 【請求項２６】 前記スペシャルＩＯクラス２とスペシ
    ャルＩＯクラス３の作業の場合に可能なかぎりスペシャ
    ルＩ／Ｏ部から装置-装置に処理することを特徴とする
    請求項２５に記載の運営体制カーネル。
27. 【請求項２７】 前記ポリシー記述表は、 システムのリソースに対して４種のアプリケーションの
    デフォルトリソース及び最大リソースの範囲をポリシー
    として記述することを特徴とする請求項１９に記載の運
    営体制カーネル。
28. 【請求項２８】 前記ポリシー記述表は、 Ｉ／Ｏ ＪＯＢクラス１、２、３、及び４に対して各ク
    ラスのアプリケーションが確保して用いることができる
    ＣＰＵ時間の最小値を所定の割合で最小リソースを割り
    当てることによって各アプリケーションに対するデフォ
    ルトリソースを割り当てる段階と、 アプリケーションの使用パターンにより４個のアプリケ
    ーションクラスが共有できる残りリソースを割り当てる
    段階と、 各々のアプリケーションクラスに対して一定な範囲のＣ
    ＰＵリソースを割り当てる段階とを含む方法により設定
    されたポリシーを含むことを特徴とする請求項２７に記
    載の運営体制カーネル。
29. 【請求項２９】 新しいアプリケーションが遂行される
    前に前記デフォルトリソース及び最大リソースの範囲を
    用いてサービス品質パラメータ交換とアドミッション制
    御とを遂行することを特徴とする請求項２８に記載の運
    営体制カーネル。
30. 【請求項３０】 スペシャルＩＯクラス１の場合、 （ａ−１）ファイルバッファを割り当てる段階と、 （ｂ−１）Ｘを所定の正の整数とする時ファイルバッフ
    ァからＸバイトを読み取る段階と、 （ｃ−１）プロトコルデータユニットによってファイル
    バッファが空いているかをチェックする段階と、 （ｄ−１）前記（ｃ−１）段階でファイルバッファが空
    いているとチェックされればフォークを遂行してディス
    ク装置をウェークアップして前記ディスク装置からデー
    タを読み出す段階と、 （ｅ−１）前記（ｄ−１）段階の結果をハイＱに貯蔵す
    る段階と、 （ｆ−１）前記（ｃ−１）段階でファイルバッファが空
    いていないとチェックされればＨＱに貯蔵されているデ
    ータを伝送して、ディスクをスリープ状態に維持させる
    段階と、 （ｇ−１）ＵＤＰデータをネットワーク装置に送る段階
    と、 （ｈ−１）発送されたＵＤＰデータをネットワーク装置
    側のバッファに貯蔵する段階と、 （ｉ−１）ネットワーク装置のバッファに貯蔵されたＵ
    ＤＰデータを媒体アクセス制御によってネットワーク装
    置に伝送する段階とを遂行して、 前記スペシャルＩ／Ｏシステムコールは（ａ−１）ない
    し（ｆ−１）段階に関与することを特徴とする請求項２
    ３に記載の運営体制カーネル。
31. 【請求項３１】 スペシャルＩＯクラス２の場合、 （ａ−２）外部音声をマイクを通して入力する段階と、 （ｂ−２）入力された外部音声を電気的な音声信号に変
    換する段階と、 （ｃ−２）ハードウェアボコーダから変換された音声信
    号をデジタル音声データに変換する段階と、 （ｄ−２）前記デジタル音声データをバッファに貯蔵す
    る段階と、 （ｅ−２）バッファに貯蔵されたデジタル音声データを
    パケット化する段階と、 （ｆ−２）パケット化されたデータをハイＱに貯蔵する
    段階と、 （ｇ−２）パケット伝送要求信号であるＲＴＰ／ユーザ
    ーデータパケットであるＵＤＰデータをネットワーク装
    置に送る段階と、 （ｈ−２）発送されたＲＴＰ／ユーザーデータパケット
    であるＵＤＰデータをネットワーク装置のバッファに貯
    蔵する段階と、 （ｉ−２）ネットワーク装置のバッファに貯蔵されたＲ
    ＴＰ／ユーザーデータパケットであるＵＤＰデータを媒
    体アクセス制御によってネットワーク装置に送る段階と
    を遂行して、 前記スペシャルＩ／Ｏシステムコールは（ｅ−２）ない
    し（ｇ−２）段階に関与することを特徴とする請求項２
    ３に記載の運営体制カーネル。
32. 【請求項３２】 前記パフォーマンス測定は、 （ｐｍ−ａ）各アプリケーションを複数のクラスに識別
    する段階と、 （ｐｍ−ｂ）アプリケーションのクラスに適合したテス
    トプログラムを用いてパフォーマンスを測定する段階と
    を含んでなることを特徴とする請求項１８に記載の運営
    体制カーネル。
33. 【請求項３３】 前記（ｐｍ−ｂ）段階は、 （ｐｍ−ｂ−１）任務重大性作業はアプリケーション特
    性に合うベンチマークプログラムを用いてどの程度のト
    ランザクションを処理できるかを測定してシステムで処
    理しなければならない最小及び最大トランザクションの
    数を決定する段階と、 （ｐｍ−ｂ−２）リソース予約を必要とするハイメディ
    アアプリケーションとＧ．７２３、及びＨ．２６３など
    の標準に従う対話形メディアアプリケーションはスケジ
    ューリング周期のようなサービス品質パラメータと、繰
    り返される重要ルーチンに対する情報をユーザーが明示
    した次に、 秒当たりエンコーディングまたはデコーデ
    ィング遂行時間を測定する段階と、 （ｐｍ−ｂ−３）その他リアルタイム処理を要しないア
    プリケーションはパフォーマンス測定を省略する段階と
    を含むことを特徴とする請求項３２に記載の運営体制カ
    ーネル。
34. 【請求項３４】 前記（ｐｍ−ｂ）段階は、 （ｐｍ−ｂ−１−ｎａ）もしも前記（ｐｍ−ｂ−１）段
    階で任務重大性作業のみを遂行することにもシステムの
    性能が足りないと決定されれば、より良い性能のシステ
    ムを用いるようにユーザーに表示する段階をさらに含む
    ことを特徴とする請求項３３に記載の運営体制カーネ
    ル。