ドライブユニットにおける非データ伝送のための時間バジェティング
【課題】イニシエータユニットのストリームバッファを利用することによるイニシエータユニットとロジカルユニットとの間のデータ伝送を効果的に管理すること。
【解決手段】イニシエータによってリクエストされる記憶媒体へのデータアクセス間において、ロジカルユニットは自律的処理を実行する必要があるかもしれない。ロジカルユニットは、イニシエータのストリームバッファが臨界レベルに達しているかロジカルユニットが判断することを可能にするため、イニシエータから情報を受け取る。この推定に基づき、ロジカルユニットは、エラーリカバリ、ドライブ機構又は記憶媒体の物理的メンテナンス、又はドライブ機構と記憶媒体との間の相対的ポジショニングなどの自律的処理を実行又は継続するか否か決定することが可能である。当該推定はまた、固定されたものよりフレキシブルなタイムアウトを可能にする。
【解決手段】イニシエータによってリクエストされる記憶媒体へのデータアクセス間において、ロジカルユニットは自律的処理を実行する必要があるかもしれない。ロジカルユニットは、イニシエータのストリームバッファが臨界レベルに達しているかロジカルユニットが判断することを可能にするため、イニシエータから情報を受け取る。この推定に基づき、ロジカルユニットは、エラーリカバリ、ドライブ機構又は記憶媒体の物理的メンテナンス、又はドライブ機構と記憶媒体との間の相対的ポジショニングなどの自律的処理を実行又は継続するか否か決定することが可能である。当該推定はまた、固定されたものよりフレキシブルなタイムアウトを可能にする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特にイニシエータユニット（ｉｎｉｔｉａｔｏｒ ｕｎｉｔ）のストリームバッファを利用することによるイニシエータユニットとロジカルユニット（ｌｏｇｉｃａｌ ｕｎｉｔ）との間のデータ伝送を管理する分野に関する。
【背景技術】
【０００２】
ある処理状態では、データを提供又は利用する１以上のアプリケーションを実行する少なくとも１つのホスト（イニシエータとしても知られる）が存在する。ホストプロセッサは、典型的には、ドライブユニット（ロジカルユニットとしても知られる）などの周辺装置とインタフェースをとる。ドライブユニットは、一般には、論理処理機能と、データ読み出し先又はデータ書き込み先となる少なくとも１つの媒体とを有する。媒体には、光、磁気、電子などの多数のタイプが存在する。
【０００３】
媒体とインタフェースをとるため、アプリケーションプログラムは、しばしば大きなバッファを有する。アプリケーションがデータを利用している場合、バッファ充填量（ｂｕｆｆｅｒ ｆｕｌｌｎｅｓｓ）がある閾値レベル未満であるときには、アプリケーションプログラムは、該当するドライブユニットからさらなるデータをリクエストする１以上のリードコマンドを発信する。アプリケーションプログラムがデータを生成している場合、バッファ空き量（ｂｕｆｆｅｒ ｅｍｐｔｉｎｅｓｓ）がある閾値レベル未満であるときには、アプリケーションプログラムは、該当するドライブユニットに少なくとも１つのライトコマンドを発信する。
【０００４】
様々なタイプの媒体に対する読み書きの際のデータをバッファリングする多数の例が存在する。このようなバッファリングの例は、参照することによりここに含まれる、ドライブユニットが、アプリケーション伝送レートにマッチしようとするため、それが媒体からデータ抽出する伝送レートをどのようにして採用するかを記載するＰＣＴアプリケーションＩＢ２００４／０５０６（ＮＬ０３０６１７）に見つけることができる。当該出願は、読み出ししか適用されず、ドライブユニット自身のバッファの充填量を考慮できる（する）。ドライブユニットは、アプリケーションのバッファについては何も知らない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明者によって見つけられた１つの問題は、データアクセスに関するタイミングがアプリケーションプログラムを充足することだけに関するものではないということである。ときには、ドライブユニット自体が、自律的な非データ伝送処理を実行する必要がある。このような処理は、エラーリカバリ、ドライブユニット又は記憶媒体の物理的メンテナンス及びドライブ機構と記憶媒体との間の相対的なポジショニングを含む。一般に、そのような処理は、記憶媒体へのデータアクセスと同じリソースを利用し、このため、そのようなアクセスと同時に実行することはできない。この結果、ドライブユニットは、それがアプリケーションプログラムを充足することが可能であるか知ることに加えて、このような自律的処理のための時間を有しているか知っている必要がある。
【課題を解決するための手段】
【０００６】
ドライブユニットがストリーミングのロスの前にどれくらいの時間が残っているか決定することを可能にするため、アプリケーションプログラムを実行しているホストプロセッサにドライブユニットを供給させることが望ましい。ドライブユニットは、この上方を利用して、例えば、フレキシブルなタイムアウトを実現することによって、又はそれがそのような処理を開始する前に自律的な非データ伝送処理を良好に実行することが可能であるか決定することによって、それの内部処理を調整することが可能である。自律的処理は、例えば、エラーリカバリ、ドライブ機構又はデータ記憶媒体の物理的メンテナンス又はドライブ機構と記憶媒体との間の相対的ポジショニングのカテゴリなどにおいて、様々なタイプのものがあるかもしれない。
【発明の効果】
【０００７】
本発明によると、イニシエータユニットのストリームバッファを利用することによるイニシエータユニットとロジカルユニットとの間のデータ伝送を効果的に管理することができる。
【図面の簡単な説明】
【０００８】
【図１】図１は、リード処理中の本発明による装置の概略を示す。
【図２】図２は、ライト処理中の本発明による装置の概略を示す。
【図３Ａ】図３Ａは、時間の関数としてのバッファの充填のグラフである。
【図３Ｂ】図３Ｂは、時間の関数としてのタイマー値のグラフである。
【図４Ａ】図４Ａは、本発明によるリード処理に関するフローチャートの第１部分である。
【図４Ｂ】図４Ｂは、本発明によるリード処理に関するフローチャートの第２部分である。
【図５Ａ】図５Ａは、本発明によるライト処理に関するフローチャートの第１部分である。
【図５Ｂ】図５Ｂは、本発明によるライト処理に関するフローチャートの第２部分である。
【図６】図６は、図４Ａ及び４Ｂのフローチャートに関するタイミング図を示す。
【図７】図７は、リード処理のためのフォアグラウンドプロセスのフローチャートを示す。
【図８】図８は、リード処理のための第２フォアグラウンドプロセスのフローチャートを示す。
【図９】図９は、ライト処理のためのバックグラウンドプロセスのフローチャートを示す。
【発明を実施するための形態】
【０００９】
図１は、本発明が利用可能な装置の一例の概略図を示す。この概略図は、ストリーミングによるリード処理を示すよう構成される。当該装置は、ロジカルユニット１０４と媒体１０７とを含むデータソース１０１を有する。ここで、「ドライブユニット」及び「ロジカルユニット」という用語は、互換的に利用される。媒体１０７は、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｃ）、ＨＤ−ＤＶＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｃ）、ＢＤ（Ｂｌｕ−らｙ Ｄｉｓｃ）などの光学的なものであるかもしれない。媒体１０７はまた、磁気又は電子などの他のタイプのものであるかもしれない。
【００１０】
当該装置はまた、ソース１０１からのデータを利用するホスト１０６を含む。ここで、「ホスト」と「イニシエータ」という用語は、互換的に使用される。ホスト１０６は、ＰＣ、デジタル信号プロセッサ、セットトップボックスなどの何れかのタイプのものであるかもしれない。ホスト１０６は、ロジカルユニット１０４による同一のハウジング又は異なるハウジングにあるかもしれない。イニシエータユニット１０６の内部には、ソース１０１内のロジカルユニット１０４からデータストリーム３を収集するコレクタモジュール（ｃｏｌｌｅｃｔｏｒ ｍｏｄｕｌｅ）１０２が存在する。ストリームバッファ１０５は、コレクタからデータ２を受け付け、ストリーミングされたデータ１をコンシューマ（ｃｏｎｓｕｍｅｒ）１０３に提供する。ストリームバッファは、好ましくは、大規模バッファ１０５である。データフロー３は、インタフェース（図示せず）を介し行われる。コンシューマモジュール１０３は、ストリーミングされたデータ１を利用するアプリケーションプログラムの一部である。
【００１１】
コンシューマ１０３は、それがストリームバッファ１０５からデータを削除することが可能な既知の最大データレートを有する。当該レートは、利用レートを呼ばれる。インタフェースは、既知の最小データ伝送レートを有する。当該レートは、インタフェースレートと呼ばれる。ソース１０１は、ロジカルユニットのキャッシュ又はバッファ１０８への媒体からの既知の最小ストリーミングデータレートを有する。この最小ストリーミングレートは、ソースレートと呼ばれる。一般に、利用レートはソースレートより小さく、ソースレートはインタフェースレートより小さい。
【００１２】
ロジカルユニットバッファ１０８は任意的なものである。当業者は、それを有しないドライブユニットを設計することが可能である。
【００１３】
一般に、リードコマンドは多数のタイプが存在するかもしれない。一部は、ストリーミングの実行を要求し、一部は要求しない。本発明は、特にストリーミングの実行を必要とする状況において有用である。例えば、ＭＭＣコマンドセットは、
・Ｒｅａｄ（１０）
・Ｒｅａｄ（１２）
を含む複数のリードコマンドを有する。上記数字（１０又は１２）は、コマンド記述子ブロックが何バイトから構成されるかを示している。これら２つのコマンドの相違は、
・Ｒｅａｄ（１０）コマンドは伝送されるべきセクタ数を指定するため２バイトのパラメータを有し、Ｒｅａｄ（１２）コマンドは４バイトのパラメータを有する。
・Ｒｅａｄ（１２）コマンドのみが、ホストが「ストリーミング」伝送を所望することを示すパラメータを有する。ドライブにとって、これは、正しいデータを送信するためリトライを実行するより（おそらく遅延して）、時間内にデータ（不具合のある、又は生成されるものであるかもしれない）を送信することがより重要であることを意味する。本発明が特に有用であるのはこのストリーミング状態である。
【００１４】
アプリケーションがデータをコンシューマに送信開始すると、真のリアルタイム制約は存在しない。従って、「ストリーミング」パラメータがスイッチオフされることによるＲｅａｄ（１２）コマンド又はＲｅａｄ（１０）コマンドによるバッファの初期的な充填を実行することが可能である。コンシューマへのデータフローの開始後、Ｒｅａｄ（１２）コマンドは、ロジカルユニットへのストリーミング伝送リクエストを示すのに利用可能なものである。
【００１５】
図３ａは、データ利用処理中における時間に対する垂直軸上のバッファ充填量のグラフを示す。バッファ充填量は、それが閾値又はトリガーレベルに達するまで、データ利用中は低下する。当該ポイントにおいて、新たなデータ伝送処理がドライブユニットを用いてアプリケーションにより開始され、これにより、バッファ充填量は再び増加する。典型的には、アプリケーションがさらなる伝送を要求することを停止するのに十分充填された第２閾値にバッファが達するまで、データが伝送される。ホストの観点から、これは、時間があるが、ドライブが当該時点を知っていない場合に、自律的処理を開始するための好適なポイントであり、このため、それは自律的処理を実行することが可能となるのに十分な情報を受信し、依然としてホストの要求を充足する必要がある。
【００１６】
図２は、図１と同様に、ライト処理中の本発明による装置の一例の概略を示す。このケースでは、データ生成モジュール２０３は、生成レートと呼ばれるレートによりデータ２１１をストリームバッファ２０５に提供する。ストリームバッファ２０５は、データ２１２を合成モジュール２０２に提供し、合成モジュール２０２は、インタフェースレートと呼ばれるレートにより送信先２０１にインタフェース（図示せず）を介しデータ２１３を提供する。その後、送信先モジュール２０１は、ここには図示されていないが、図１に示されるそれのローカル媒体に、送信先ライトレートと呼ばれるレートにより書き込みを行う。図２のモジュールは、アプリケーションに応じて図１における同様のモジュールと同一であり、すなわち、それらの参照番号の同一の最後の２桁を有するモジュールと同一のものとすることが可能である。あるいは、それらは異なるモジュールであるかもしれない。アプリケーションが生成するすべてのデータが記録可能であることを確認するため、ドライブユニットが書き込み可能なレートは、生成レートより大きなものとなる必要がある。これは、小さすぎるインタフェース伝送レートによって阻害されてはならない。
【００１７】
再び、ＭＭＣ−４ Ｗｒｉｔｅ（１２）コマンドなどの書き込み状態においてストリーミング伝送の実行が必要とされることをロジカルユニットに通知するのに利用可能な各種コマンドが多数存在する。
【００１８】
図３ａはまた、ライト処理中における時間の関数としてバッファ空き量の表示として利用することが可能である。すなわち、書き込み中、バッファ空き量は、データ伝送がドライブユニットを用いてアプリケーションにより開始される閾値又はトリガー値に達するまで低下する。データ伝送は、第２閾値に達するまでバッファ空き量を徐々に増大させる。アプリケーションプログラムは、第２閾値到達後、データ伝送を要求することを停止する。これは、ドライブユニットが自律的処理を開始することが可能となるポイントである。それは、リカバリ又はキャリブレーションが取得するタイマーの値と時間量から、それが息つく時間（ｔｉｍｅ ｔｏ ｂｒｅａｔｈ）を有していることしか知らない。
【００１９】
通常、自律的な非データ伝送処理に利用可能な時間に関する情報は、コマンドを用いてホスト１０６／２０６からドライブユニット１０１／２０１に通信されるべきである。好ましくは、このようなコマンドは、
・初期的なストリームタイミング値（ＩＳＴＶ）
・伝送ユニットサイズ（ＴＵＳ）
・伝送ユニットインクリメント（ＴＵＩ）
・リード又はライト処理が所望されるか示すライトフラグ
の４つのパラメータを含むであろう。
【００２０】
これらは、どのようにパラメータが設定されるかの単なる具体例である。当業者は、他のパラメータを創出するかもしれない。例えば、タイミング値を送信するのでなく、アプリケーションは、ストリーミングバッファにすでにあるデータ量の数量とデータ利用レートを送信するかもしれない。これらの値から、ドライブユニットは、残りの時間を計算することが可能である。利用レートは、ＴＵＳ／ＴＵＩとみなすことが可能である。
【００２１】
図７は、データ伝送のためドライブユニットにおいて動作するフォアグラウンドプロセスの一例を示す。まず７０１において、ドライブユニットは、ホストユニットから上記列挙されたようなタイムアウトパラメータを受け取る。その後７０２において、ドライブユニットはこれらのパラメータを格納する。その後７０３において、ドライブユニットは、タイムアウトカウンタをスタートする。
【００２２】
タイマーは、連続的にカウントダウンする。ドライブがライトフラグにより決定される方向にサイズＴＵＳのデータ量を伝送する毎に、ドライブはＴＵＩを実際のカウンタ値に加えるようにしてもよい。このことは、時間の関数としてタイマーの値をグラフ化した図３ｂに示される。この場合、カウンタ値の増加は、ジグザグのラインに従う。ＴＵＩの追加は、伝送ユニットの伝送の終わりまでタイマー値を増加させるが、この同じ伝送中にタイマー値を低下させる。従って、タイマー値は、ストリーミングバッファの値のジグザグの近似又は推定となる。
【００２３】
図８は、ドライブユニットにおいてリードリクエストが動作する第２のフォアグラウンドプロセスを示す。８０１において、ドライブユニットはリードリクエストを受け取る。８０２においてリードコマンドが、Ｒｅａｄ（１０）などストリーミングを要求しない場合、当該コマンドは、８０３におけるストリーミング要求なしに処理される。８０２においてリードコマンドが、Ｒｅａｄ（１２）などのストリーミングを要求する場合、当該プロセスは、タイマーが経過したか８０６においてテストする。そうである場合、当該コマンドは、８０５においてエラーにより終了する。そうでない場合、当該プロセスは、８０７においてすべてのデータが伝送されたかテストする。そうである場合、当該コマンドは、８０９において良好に終了する。そうでない場合、８０８において、バックグラウンドプロセスからのデータを待機することが可能である。８１０において、利用可能なデータが伝送され、その後８１１において、タイマーが更新される。その後、コントロールは８０６に戻る。
【００２４】
バックグラウンドプロセスファンクション８０８からのデータ待機は、データがバックグラウンドプロセスによってディスクからすでにフェッチされている場合には、極めて迅速にリターンするかもしれない。そうでない場合、フォアグラウンドプロセスは、データが利用可能になるとすぐに、バックグラウンドプロセスによってトリガーされる。もちろん、致命的なエラーが発生する可能性があるが、これはフローチャートには示されていない。
【００２５】
ストリーミング要求なしにコマンドを処理する間、タイマーは依然としてカウントダウンする。なぜなら、コンシューマはアプリケーションのストリームバッファからのデータを依然として利用しているためである。
【００２６】
また、ドライブユニットがリード処理中に媒体に不具合を検出し、リカバリ及び／又はキャリブレーションを実行する実用があると仮定する。この質問は、「コンシューマに対するリアルタイム要求を危険にさらすことなく、このリカバリ処理にドライブがどのくらいの時間費やすことが許されるか」というものである。その回答は、実際には、アプリケーションバッファの充填量に依存する。当該バッファがデータにより充填されている限り、ドライブはそれのリカバリを継続することが可能である。しかしながら、バッファ占有がゼロに接近しているとき、ドライブのリカバリは停止される必要がある。
【００２７】
一般に、インタフェースがこれをサポートしないため、アプリケーションはリカバリを停止することができない。この結果、ドライブユニットは、それのローカルタイマーのタイムアウト値がある閾値に到達すると、自らリカバリを停止しなければならない。しばしば、ドライブユニットは、自律的処理を実行している間にホストに提供可能なキャッシュ１０８と呼ばれるバッファ自体を有するであろう。これは、自律的処理に対するビットにより多くの時間を与えるかもしれないが、ドライブユニットのバッファはストリーミングバッファと比較して一般に小さいものであるため、この余分な時間は重要ではないかもしれない。
【００２８】
図９は、ボックス８０８により利用されるバックグラウンドリードプロセスの一例を示す。当該プロセスは、キャリブレーションと呼ばれる非データ伝送処理を実行しようとするものである。読み込みの際、ドライブはプリフェッチ処理と呼ばれるタスクを実行する。このことは、バックグラウンドプロセスが、さらに（連続するデータ）アプリケーションからの以降のリクエストを予想することができるように、ドライバのバッファがフルになるまで、ディスクからのデータの読み込みを継続することを意味する。これは、ループにおいて行われているものであり、フォアグラウンドプロセスをトリガーした後、バックグラウンドプロセスがデータを読み込み、又は非データ伝送処理を実行し続ける（ドライブユニットにより内部的に要求される場合）ことが可能であり、これにより、そのような処理は、好ましくはバックグラウンドプロセスにおいて実行される。
【００２９】
９０１において、バックグラウンドは、データをドライブユニットのバッファにプリフェッチする。その後９０２において、それはデータが利用可能であるかチェックする。
【００３０】
そうである場合、９０７において、それはフォアグラウンドプロセスをトリガーする。そうでない場合、当該プロセスは、キャリブレーションが９０３において保留中であるか判断する。そうでない場合、９０６において、データはドライブからバッファに伝送され、フォアグラウンドプロセスが９０７においてトリガーされる。
【００３１】
キャリブレーションが保留中である場合、バックグラウンドプロセスは、９０４においてタイムアウトカウンタが非データ伝送処理に対して十分であるかテストする。そうである場合、非データ伝送処理、この場合にはキャリブレーションリクエストが、９０５において実行され、コントロールが９０６にわたされる。非データ伝送処理の時間がない場合、コントロールは、９０５を通過して９０６に直接わたされる。
【００３２】
図７〜９のフローチャートは、パラレルに実行されるべきである。
【００３３】
図４ａ及び４ｂは、エラーの場合における本発明による自律的処理を要求するリード処理のためのフローチャートの一例を示す。
【００３４】
４０１において、ホストは、ＩＳＴＶ、ＴＵＳ、ＴＵＩ及びＷＲＩＴＥパラメータを計算し、その最後はフラグである。その後４０２において、ホストは、後述されるようなセットストリーミングコマンドの「ストリームタイミング記述子」を介しこれらのパラメータを送信する。ドライブは、セットストリーミングコマンドを受け取り、４０３においてストリームタイミング記述子からこれらのパラメータを取得する。その後４０４において、ドライブは、ＩＳＴＶによるダウンカウンタをプログラムし、その他のパラメータを格納する。ここで、ホストは、４０５においてＲｅａｄ（１２）などの少なくとも１つのリードコマンドを送信し、ドライブは、４０６においてリードコマンドを受け取る。フローチャートコネクタＸは、図４ａと４ｂとの間の実行のフローを接続するのに利用される。４１０において、ドライブはディスクから１以上のセクタを読み取る。ドライブユニットがまたバッファを有する場合、データはすでに利用可能であるかもしれない。
【００３５】
その読み込み中、４１１において、ドライブユニットによっていくつかのエラーが検出されるかもしれない。そうである場合、ドライブは、４１８において自律的リードリカバリ処理を実行しなければならない。まず、ドライブは、４２３において自律的処理を実行するのに十分な時間があるかテストする。十分な時間がない場合、ドライブは、４２１においてコネクタＷを介しエラーメッセージを生成する。十分な時間がある場合、コントロールはボックス４１８にわたされる。これらの処理の実行中、ドライブはまた、カウントダウンカウンタ／タイマーをモニタする必要がある。４１９において、カウントダウンがゼロに達する場合、４２２において当該リードはタイムアウトとなる。４２０において、カウントダウンがゼロに到達しないが、リードリカバリが成功しない場合、当該リードは、４２１においてリカバリ不可能なエラーにより終了する必要がある。
【００３６】
４２０において、リードリカバリが成功した場合、ドライブは、４１２において利用可能なデータを示し、それはまた、４１１においてエラーがない場合には、その結果となる。その後、図３ｂに示されるように、ホストは４１２においてドライブからホストにデータを伝送することが可能であり、ドライブは４１４においてダウンカウンタを更新する。ダウンカウンタのこの更新は、フレキシブルなタイムアウトを実現する。ドライブのダウンカウンタが４１５においてゼロに到達する場合、リードタイムアウトがまた実行され、４２２においてリードの終了が不成功となる。ドライブのダウンカウンタが４１５においてゼロに到達しない場合、ドライブは、要求されたすべてのデータが４１６において伝送されたかテストする。そうでない場合、コントロールはボックス４１０に戻る。そうである場合、ドライブは、伝送コマンドが４１７において成功したことを通知する。
【００３７】
図５ａ及び５ｂは、本発明による自律的処理を要求するライト処理のためのフローチャートの一例を示す。
【００３８】
５０１において、ホストは、ＩＳＴＶ、ＴＵＳ、ＴＵＩ及びＷＲＩＴＥパラメータを計算し、その最後がフラグとなる。その後５０２において、ホストは、セットストリーミングコマンドにおいて「ストリームタイミング記述子」を介しパラメータを送信する。ドライブは、５０３において、セットストリーミングコマンドを受け取り、ストリームタイミング記述子からパラメータを取得する。その後５０４において、ドライブは、ＩＳＴＶによりダウンカウンタをプログラムし、その他のパラメータを格納する。ホストは、５０５において少なくとも１つのライトコマンドを送信し、ドライブは、５０６においてライトコマンドを受け取る。５０７において、ドライブは、ホストからデータをリクエストする。その後、ホストは、５０８において１以上のデータブロックをドライブに送信し、５０９において、ドライブはそれを受け付ける。コネクタＹ及びＺが、図５ａ及び５ｂのフローチャート部分を接続するのに利用される。５１０において、ドライブは、ダウンカウンタ、すなわち、タイマーを更新し、これにより、フレキシブルなタイムアウトを実現する。
【００３９】
ダウンカウンタが５１１においてゼロに到達した場合、ライトコマンドは、５２０において、タイムアウト状態により終了する。そうでない場合、ドライブは５１２において、ディスクに書き込みを行う。５１３において、この書き込みによるエラーが検出されると、ドライブは、５１６において自律的なライトリカバリを実行しなければならない。まず、ドライブは５２２において、自律的処理を実行するための時間があるかテストする必要がある。時間がない場合には、５１９において、コネクタＶを介しリカバリ不可能なエラーが生ずる。時間がある場合には、コントロールはボックス５１６にわたされる。ライトリカバリ期間中、ドライブはまた、５１７においてカウントダウンをモニタしなければならない。ドライブのカウントダウンが５１７においてゼロに到達すると、ライトコマンドは、５２０においてタイムアウト状態により終了しなければならない。そうでない場合には、ドライブは、ライトリカバリが５１８において成功したかテストする。不成功であった場合、ライトコマンドは、５１９においてリカバリ不可能なエラーにより終了される。ライトリカバリが成功した場合、コントロールはボックス５１４にわたされ、それはまた、５１３においてエラーが検出されていなければ、コントロールがわたされたであろう場合である。
【００４０】
５１４において、ドライブは、関連するすべてのデータが伝送されたかテストする。そうでない場合、コントロールはブロック５０７に戻る。そうである場合、ドライブは、伝送コマンドが５２１において成功したと判断する。
【００４１】
処理５１９、５２０、５２１、４１７、４２１及び４２２のすべては、ドライブがデータ伝送処理の結果に関する通知をホストに提供することを要求する。
【００４２】
図４ａ、４ｂ、５ａ及び５ｂのフローチャートは、シーケンシャルタイプフォーマットにより書かれているが、それらはまた、図７〜９と同様に、パラレルタイプフォーマットにより設定することが可能である。
【００４３】
ドライブユニットは、レイヤジャンプ、熱管理動作又はリトライなどの他の自律的処理を実行するかもしれない。一般に、自律的処理は、例えば、ドライブ機構又はデータ記憶媒体の物理的メンテナンス又はドライブ機構と記憶媒体との間の相対的ポジショニングのカテゴリなど、各種タイプを有するかもしれない。
【００４４】
何れのケースでも、当該タイプの自律的処理は、ホストに透過であるべきである。コマンドを処理しているフォアグラウンドプロセスは、ドライブユニットのキャッシュにデータが到着することを待機するだけである。それは、データが到着することを待機している理由は知らず、知る必要もない。
【００４５】
当業者は、図４ａ及びｂ並びに図５ａ及びｂと同様又は図７〜９と同様の他の実現形態を、特にボックス４１０、４１１、４１８、５１２、５１３及び５１６に対する若干の修正により上記及び他のタイプの自律的処理のため創出することが可能である。
【００４６】
レイヤジャンプの場合、リード中において、それはボックス４１０の一部として実行することが可能である。レイヤジャンプは、記憶媒体に対する動きの一例である。ディスクからセクタを読み取ることは、光学ヘッドは適切な位置に移動されることを要求する。これは、他のレイヤ上にあるかもしれず、そのためレイヤジャンプと呼ばれる。
【００４７】
フローチャートは、ストリーミングバッファ上のタイムアウトの場合に、永続的に終了する自律的処理を示す。しかしながら、いくつかの自律的処理は十分重要であるため、タイムアウトがあったとしても、それらが進行すべきである。例えば、熱管理処理は、記憶媒体への損害を回避するのに十分な時間がなくても必要であるかもしれない。このような場合、タイムアウトエラーメッセージは、熱管理動作の後に又はそれとパラレルに発行することが可能である。
【００４８】
ボックス５２２及び４２３は、ストリーミングのロスまでの時間が自律的処理を実行するのに必要な時間より大きいか判断する必要がある。以下のテーブルにおいて、ストリーミングのロスまでの時間に関する計算例が示される。
【００４９】
【表１】
ただし、
・Ｃは、Ｋ秒より少なくない期間に試用されるバイトグループ数であり、
・Ｎは、好適なリード又はライトサイズを生成するためＣと乗算可能な乗数であり、
・Ｘは、予め決定されたストリームバッファ充填ポイントである。
【００５０】
一般に、本発明による及びロジカルユニットにおける自律的処理は、コマンド実行中又はコマンド間において実行されるかもしれない。
【００５１】
「コマンド実行中」とは、フローチャートに記載された状況であり。本発明は、ＭＭＣ４からの固定されたタイムアウトに関する基本的問題を解決する。アプリケーションはタイムアウトが指定されることを可能にする。しかしながら、このタイムアウトは、宅コマンドの実行に適用され、従って、これは各コマンドの到着において再開される固定されたタイムアウトである。この定義による問題は、複数のコマンドのタイムアウトを加えることができないということである。本発明のタイムアウトは、実際にはプロセスのタイムアウトであり、単一のコマンドのものではなく、すなわち、フレキシブル又はランニングタイムアウトである。
【００５２】
他の実施例では、コマンド実行中、ドライブは自律的処理がどれくらい重要であるかテストすることが可能であり、その後、データ伝送コマンドの終了前に当該処理が実際にすぐに必要とされる場合には、自律的処理のみをスタートする。他の実施例では、ドライブユニットは、自律的処理に費やすことが可能な時間に関する制限を確立することが可能である。
【００５３】
本発明はまた、コマンド間において利用可能である。これらの状況では、ドライブは、データ伝送以外の動作を自律的かつ安全に実行することが可能である。本発明のタイマー値は、単一のコマンドでなくプロセスに対するランニングタイマーである。従って、バックグラウンドで非データ伝送処理を実行しながら、ドライブは依然として、ストリーミング要求に関する新たな情報を受け取ることが可能であり、コマンド処理はフォアグラウンドタスクとなる。
【００５４】
本発明により維持されるタイムアウト値は、コンシューマへの実際の伝送レートが可変である場合（圧縮により）、不正確なものとなるかもしれない。従って、アプリケーションは、タイマー値を定期的に更新する必要がある。
【００５５】
イニシエータは、かなり多数のセクタが伝送される必要がある１つのコマンドを発行するかもしれないが、少数のセクタにより多数のコマンドを発行するかもしれない。前者のケースでは、非データ伝送処理はコマンドの実行中に行うことが可能であり、後者のケースでは、非データ伝送処理はまた、適切なタイマー値がドライブユニットに伝送し続けられる限り、コマンド間で行われるかもしれない。ドライブユニットがまたキャッシュを有するため、それは、非データ伝送処理をパラレルに実行しながら（リトライ、エラーリカバリ、キャリブレーションなどと同様に）、キャッシュからのこれら多数のコマンドのいくつかに対するセクタを伝送することが可能であるかもしれない。
【００５６】
しかしながら、「コマンド実行中」とは、ドライブが記憶媒体に対するデータの読み書きとパラレルに非データ処理を必然的に実行可能であることを意味するものでないということに留意すべきである。ドライブは単に、本発明のタイミング計算を利用して、記憶媒体への実際のデータアクセスが不要となる時間を活用する。
【００５７】
図６は、リード処理中の経過時間の関数としてのバッファ充填量のグラフを示す。同様のグラフが、ライト処理に適用されるであろう。６０１において、バッファ充填量は、ジャンプバックレベル６０３に到達する。これは、リード処理に対するトリガーとして利用される。第１期間６０４の期間中、データ伝送が実際に開始されるまで、充填量は低下し続ける。参照番号６０５は、データ伝送が行われない場合のタイムアウトまでの期間を示す。参照番号６０６は、フローチャートの４２２において示される状態Ｃのバッファ充填量が続く、すなわち、自律的処理が長くかかりすぎた場合を示す。参照番号６０７及び６０８は、タイミング図のブランチＡ及びＢに対する期間を参照する。これらのブランチは共に、ブロック４１７毎に成功した読み込みに関するが、ブランチＡでは、バッファ充填量はジャンプバックレベル以下には低下せず、ブランチＢでは、バッファ充填量はタイムアウトを生じさせることなく、ジャンプバックレベル以下に低下する。
【００５８】
ホストユニットとドライブとの間で送信されるコマンドは、ＭＭＣ−４規格に見つけられるものなどのフォーマットによるものであってもよく、その草案は、ｈｔｔｐ：／／ｗｗｗ．ｔ１０．ｏｒｇ／ｆｔｐ／ｔ１０／ｄｒａｆｔｓ／ｍｍｃ４／ｍｍｃ４ｒ０３．ｐｄｆに存在する。好適な実施例は、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドを利用して、本発明に関するパラメータをわたす。当業者は、例えば、既存のコマンド又は新しいコマンドを含む他のＭＭＣタイプコマンドを利用することによって、他の通信技術を創出することが可能である。
【００５９】
以下において、本発明を実現するためのＭＭＣタイプ状況における利用に適したコマンドフォーマットが記載される。これらは単なる具体例である。当業者は、本発明が機能する他のフォーマット又はコマンドの利用を創出するかもしれない。
【００６０】
イニシエータは、プロファイル及びフィーチャに関するドライブユニットのすべての機能を取得するため、“ＧＥＴ ＣＯＮＦＩＧＵＲＡＴＩＯＮ”コマンドを発行する。搭載されている媒体に依存して、一部のプロファイル及びフィーチャは現在のものとされる。
【００６１】
プロファイルの現在性は、ドライブユニットによりサポートされるフィーチャのベースセットを規定する。さらに、あるフィーチャは、ドライブユニットの機能及び動作を指定するコマンド及びモードページセットを記述する。
【００６２】
テーブル２において、イニシエータに返されるべきリアルタイムストリーミングフィーチャに対するフィーチャ記述子レスポンスデータが規定される。
【００６３】
【表２】
これの大部分は、“Ｓｔｒｅａｍｅｄ Ｔｉｍｉｎｇ（ＳＴ）”ビットが追加されることを除いて、ＭＭＣ−４規格に従っている。当該ビットが１である場合、それは、当該ロジカルユニットが“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドの“Ｓｔｒｅａｍｅｄ Ｔｉｍｉｎｇ”記述子をサポートしていることを示す。
【００６４】
このフィーチャをサポートするロジカルユニットは、テーブル３に列挙されるコマンドを実現する。
【００６５】
【表３】
［ＳＥＴ ＳＴＲＥＡＭＩＮＧコマンド］
ステップ４０２及び５０２は、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドを利用して、“Ｓｔｒｅａｍ Ｔｉｍｉｎｇ”記述子をドライブユニットに送信することに関する。
【００６６】
“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドは、イニシエータにデータレートに対する要求を通信する方法を提供する。実行設定は永続的なものであり、新たな記述子が送信されるまで残る。
【００６７】
“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドが実行設定に利用される場合、ロジカルユニットは、実行基準を満たすため、指定された領域におけるリード及びライト再割当てを不可とするかもしれない。
【００６８】
テーブル４は、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドに係るフィーチャを示す。
【００６９】
【表４】
［ＣＤＢ及びそれのパラメータ］
テーブル５において、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ ＣＤＢ”が示される。
【００７０】
【表５】
［タイプ］
タイプフィールド（テーブル６）は、何れのタイプのデータが伝送されるか示している。
【００７１】
【表６】
このテーブルは、パフォーマンス記述子（ＭＭＣ−４に存在する）、ストリームタイミング記述子及びＤＢＩキャッシュゾーン記述子（ＭＭＣ−４に存在する）のおそらく送信可能な３つの記述子を記載している。
［コマンド実行］
“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドは、アプリケーションがロジカルユニットの実行の対する具体的リクエスト又は要求を有していることをイニシエータがロジカルユニットに示す方法を提供する。
［ストリームタイミング記述子］
以下のテーブル７の特にバイト４〜１５のストリームタイミング記述子は、イニシエータ及びロジカルユニットがストリームの連続性を維持するためにタイミング情報を共有することを可能にする。
【００７２】
ロジカルユニットは、ストリームメンテナンスに利用可能な時間を表す利用可能タイマーを維持する。利用可能タイマーは、カウントダウンタイマーである。ストリームタイミングがイネーブルとされ、利用可能タイマーがゼロに達すると、ストリーミング“ＵＮＩＴ ＡＴＴＥＮＴＩＯＮ”状態のロスが存在する。
【００７３】
【表７】
［イネーブル］
イネーブルがゼロに設定されると、ストリームタイミング記述子に基づく現在アクティブなすべてのストリームタイミングファンクションが不可とされる。イネーブルが１に設定されると、ストリームタイミングは、含んでいる記述子のパラメータに従ってイネーブルとされる。
［ライト］
イネーブルが１に設定され、ライトがゼロに設定されると、読み出しのためのストリーミングタイミングファンクションがイネーブルとされ、リードのためのストリーミングタイミングが、当該記述子のパラメータに従って初期化される。
【００７４】
イネーブルが１に設定され、ライトが１に設定されると、書き込みのためのストリームタイミングファンクションはイネーブルとされ、ライトのためのストリームタイミングは、当該記述子のパラメータに従って初期化される。
【００７５】
イネーブルがゼロに設定されるときは常に、ライトビットは規定されない。
［ストリームタイミング初期値］
ストリームタイミング初期値は、ストリーミング“ＵＮＩＴ ＡＴＴＥＮＴＩＯＮ”状態のロスが存在するまでのミリ秒数を表す。
【００７６】
イネーブルが１に設定されると、ロジカルユニットは、それの利用可能時間タイマーをストリームタイミング初期値に初期化し、利用可能タイマーをスタートする。
【００７７】
イネーブルがゼロに設定されているときは常に、当該パラメータは規定されない。
［伝送ユニットサイズ］
伝送ユニットサイズは、伝送毎の好適なセクタ数である。
［伝送ユニットインクリメント］
伝送ユニットインクリメントは、伝送ユニットサイズセクタが伝送された後、利用可能時間タイマーに加えられるミリ秒数である。
【００７８】
本開示を参照することから、当業者には他の改良が明らかになるであろう。このような改良は、イニシエータとロジカルユニットの間のデータ伝送のための装置の設計、製造及び利用についてすでに知られ、ここですでに記載された特徴の代わりに、又はそれに加えて利用可能な他の特徴に関するものであるかもしれない。本出願では、特定の特徴の組み合わせにタイする請求項が記載されているが、本出願の開示の範囲はまた、本発明と同一の技術的問題の何れか又はすべてを軽減するか否に関係なく、明示的又は非明示的にここで開示されている新規な特徴又は新規な特徴の組み合わせ又はそれの何れかの一般化を含む。本出願人は、本出願又はそれから派生するさらなる出願の手続において、新たな請求項がそのような特徴に規定されるということを通知する。
【００７９】
ここで使用される「有する」という用語は、さらなる要素を排除するものとしてみなされるものではない。ここで使用される単数形の冠詞「ある」は、複数の要素を排除するものとしてみなされるものではない。
【符号の説明】
【００８０】
１０１ データソース
１０４ ロジカルユニット
１０６ ホスト
１０７ 媒体
【技術分野】
【０００１】
本発明は、特にイニシエータユニット（ｉｎｉｔｉａｔｏｒ ｕｎｉｔ）のストリームバッファを利用することによるイニシエータユニットとロジカルユニット（ｌｏｇｉｃａｌ ｕｎｉｔ）との間のデータ伝送を管理する分野に関する。
【背景技術】
【０００２】
ある処理状態では、データを提供又は利用する１以上のアプリケーションを実行する少なくとも１つのホスト（イニシエータとしても知られる）が存在する。ホストプロセッサは、典型的には、ドライブユニット（ロジカルユニットとしても知られる）などの周辺装置とインタフェースをとる。ドライブユニットは、一般には、論理処理機能と、データ読み出し先又はデータ書き込み先となる少なくとも１つの媒体とを有する。媒体には、光、磁気、電子などの多数のタイプが存在する。
【０００３】
媒体とインタフェースをとるため、アプリケーションプログラムは、しばしば大きなバッファを有する。アプリケーションがデータを利用している場合、バッファ充填量（ｂｕｆｆｅｒ ｆｕｌｌｎｅｓｓ）がある閾値レベル未満であるときには、アプリケーションプログラムは、該当するドライブユニットからさらなるデータをリクエストする１以上のリードコマンドを発信する。アプリケーションプログラムがデータを生成している場合、バッファ空き量（ｂｕｆｆｅｒ ｅｍｐｔｉｎｅｓｓ）がある閾値レベル未満であるときには、アプリケーションプログラムは、該当するドライブユニットに少なくとも１つのライトコマンドを発信する。
【０００４】
様々なタイプの媒体に対する読み書きの際のデータをバッファリングする多数の例が存在する。このようなバッファリングの例は、参照することによりここに含まれる、ドライブユニットが、アプリケーション伝送レートにマッチしようとするため、それが媒体からデータ抽出する伝送レートをどのようにして採用するかを記載するＰＣＴアプリケーションＩＢ２００４／０５０６（ＮＬ０３０６１７）に見つけることができる。当該出願は、読み出ししか適用されず、ドライブユニット自身のバッファの充填量を考慮できる（する）。ドライブユニットは、アプリケーションのバッファについては何も知らない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明者によって見つけられた１つの問題は、データアクセスに関するタイミングがアプリケーションプログラムを充足することだけに関するものではないということである。ときには、ドライブユニット自体が、自律的な非データ伝送処理を実行する必要がある。このような処理は、エラーリカバリ、ドライブユニット又は記憶媒体の物理的メンテナンス及びドライブ機構と記憶媒体との間の相対的なポジショニングを含む。一般に、そのような処理は、記憶媒体へのデータアクセスと同じリソースを利用し、このため、そのようなアクセスと同時に実行することはできない。この結果、ドライブユニットは、それがアプリケーションプログラムを充足することが可能であるか知ることに加えて、このような自律的処理のための時間を有しているか知っている必要がある。
【課題を解決するための手段】
【０００６】
ドライブユニットがストリーミングのロスの前にどれくらいの時間が残っているか決定することを可能にするため、アプリケーションプログラムを実行しているホストプロセッサにドライブユニットを供給させることが望ましい。ドライブユニットは、この上方を利用して、例えば、フレキシブルなタイムアウトを実現することによって、又はそれがそのような処理を開始する前に自律的な非データ伝送処理を良好に実行することが可能であるか決定することによって、それの内部処理を調整することが可能である。自律的処理は、例えば、エラーリカバリ、ドライブ機構又はデータ記憶媒体の物理的メンテナンス又はドライブ機構と記憶媒体との間の相対的ポジショニングのカテゴリなどにおいて、様々なタイプのものがあるかもしれない。
【発明の効果】
【０００７】
本発明によると、イニシエータユニットのストリームバッファを利用することによるイニシエータユニットとロジカルユニットとの間のデータ伝送を効果的に管理することができる。
【図面の簡単な説明】
【０００８】
【図１】図１は、リード処理中の本発明による装置の概略を示す。
【図２】図２は、ライト処理中の本発明による装置の概略を示す。
【図３Ａ】図３Ａは、時間の関数としてのバッファの充填のグラフである。
【図３Ｂ】図３Ｂは、時間の関数としてのタイマー値のグラフである。
【図４Ａ】図４Ａは、本発明によるリード処理に関するフローチャートの第１部分である。
【図４Ｂ】図４Ｂは、本発明によるリード処理に関するフローチャートの第２部分である。
【図５Ａ】図５Ａは、本発明によるライト処理に関するフローチャートの第１部分である。
【図５Ｂ】図５Ｂは、本発明によるライト処理に関するフローチャートの第２部分である。
【図６】図６は、図４Ａ及び４Ｂのフローチャートに関するタイミング図を示す。
【図７】図７は、リード処理のためのフォアグラウンドプロセスのフローチャートを示す。
【図８】図８は、リード処理のための第２フォアグラウンドプロセスのフローチャートを示す。
【図９】図９は、ライト処理のためのバックグラウンドプロセスのフローチャートを示す。
【発明を実施するための形態】
【０００９】
図１は、本発明が利用可能な装置の一例の概略図を示す。この概略図は、ストリーミングによるリード処理を示すよう構成される。当該装置は、ロジカルユニット１０４と媒体１０７とを含むデータソース１０１を有する。ここで、「ドライブユニット」及び「ロジカルユニット」という用語は、互換的に利用される。媒体１０７は、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｃ）、ＨＤ−ＤＶＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｃ）、ＢＤ（Ｂｌｕ−らｙ Ｄｉｓｃ）などの光学的なものであるかもしれない。媒体１０７はまた、磁気又は電子などの他のタイプのものであるかもしれない。
【００１０】
当該装置はまた、ソース１０１からのデータを利用するホスト１０６を含む。ここで、「ホスト」と「イニシエータ」という用語は、互換的に使用される。ホスト１０６は、ＰＣ、デジタル信号プロセッサ、セットトップボックスなどの何れかのタイプのものであるかもしれない。ホスト１０６は、ロジカルユニット１０４による同一のハウジング又は異なるハウジングにあるかもしれない。イニシエータユニット１０６の内部には、ソース１０１内のロジカルユニット１０４からデータストリーム３を収集するコレクタモジュール（ｃｏｌｌｅｃｔｏｒ ｍｏｄｕｌｅ）１０２が存在する。ストリームバッファ１０５は、コレクタからデータ２を受け付け、ストリーミングされたデータ１をコンシューマ（ｃｏｎｓｕｍｅｒ）１０３に提供する。ストリームバッファは、好ましくは、大規模バッファ１０５である。データフロー３は、インタフェース（図示せず）を介し行われる。コンシューマモジュール１０３は、ストリーミングされたデータ１を利用するアプリケーションプログラムの一部である。
【００１１】
コンシューマ１０３は、それがストリームバッファ１０５からデータを削除することが可能な既知の最大データレートを有する。当該レートは、利用レートを呼ばれる。インタフェースは、既知の最小データ伝送レートを有する。当該レートは、インタフェースレートと呼ばれる。ソース１０１は、ロジカルユニットのキャッシュ又はバッファ１０８への媒体からの既知の最小ストリーミングデータレートを有する。この最小ストリーミングレートは、ソースレートと呼ばれる。一般に、利用レートはソースレートより小さく、ソースレートはインタフェースレートより小さい。
【００１２】
ロジカルユニットバッファ１０８は任意的なものである。当業者は、それを有しないドライブユニットを設計することが可能である。
【００１３】
一般に、リードコマンドは多数のタイプが存在するかもしれない。一部は、ストリーミングの実行を要求し、一部は要求しない。本発明は、特にストリーミングの実行を必要とする状況において有用である。例えば、ＭＭＣコマンドセットは、
・Ｒｅａｄ（１０）
・Ｒｅａｄ（１２）
を含む複数のリードコマンドを有する。上記数字（１０又は１２）は、コマンド記述子ブロックが何バイトから構成されるかを示している。これら２つのコマンドの相違は、
・Ｒｅａｄ（１０）コマンドは伝送されるべきセクタ数を指定するため２バイトのパラメータを有し、Ｒｅａｄ（１２）コマンドは４バイトのパラメータを有する。
・Ｒｅａｄ（１２）コマンドのみが、ホストが「ストリーミング」伝送を所望することを示すパラメータを有する。ドライブにとって、これは、正しいデータを送信するためリトライを実行するより（おそらく遅延して）、時間内にデータ（不具合のある、又は生成されるものであるかもしれない）を送信することがより重要であることを意味する。本発明が特に有用であるのはこのストリーミング状態である。
【００１４】
アプリケーションがデータをコンシューマに送信開始すると、真のリアルタイム制約は存在しない。従って、「ストリーミング」パラメータがスイッチオフされることによるＲｅａｄ（１２）コマンド又はＲｅａｄ（１０）コマンドによるバッファの初期的な充填を実行することが可能である。コンシューマへのデータフローの開始後、Ｒｅａｄ（１２）コマンドは、ロジカルユニットへのストリーミング伝送リクエストを示すのに利用可能なものである。
【００１５】
図３ａは、データ利用処理中における時間に対する垂直軸上のバッファ充填量のグラフを示す。バッファ充填量は、それが閾値又はトリガーレベルに達するまで、データ利用中は低下する。当該ポイントにおいて、新たなデータ伝送処理がドライブユニットを用いてアプリケーションにより開始され、これにより、バッファ充填量は再び増加する。典型的には、アプリケーションがさらなる伝送を要求することを停止するのに十分充填された第２閾値にバッファが達するまで、データが伝送される。ホストの観点から、これは、時間があるが、ドライブが当該時点を知っていない場合に、自律的処理を開始するための好適なポイントであり、このため、それは自律的処理を実行することが可能となるのに十分な情報を受信し、依然としてホストの要求を充足する必要がある。
【００１６】
図２は、図１と同様に、ライト処理中の本発明による装置の一例の概略を示す。このケースでは、データ生成モジュール２０３は、生成レートと呼ばれるレートによりデータ２１１をストリームバッファ２０５に提供する。ストリームバッファ２０５は、データ２１２を合成モジュール２０２に提供し、合成モジュール２０２は、インタフェースレートと呼ばれるレートにより送信先２０１にインタフェース（図示せず）を介しデータ２１３を提供する。その後、送信先モジュール２０１は、ここには図示されていないが、図１に示されるそれのローカル媒体に、送信先ライトレートと呼ばれるレートにより書き込みを行う。図２のモジュールは、アプリケーションに応じて図１における同様のモジュールと同一であり、すなわち、それらの参照番号の同一の最後の２桁を有するモジュールと同一のものとすることが可能である。あるいは、それらは異なるモジュールであるかもしれない。アプリケーションが生成するすべてのデータが記録可能であることを確認するため、ドライブユニットが書き込み可能なレートは、生成レートより大きなものとなる必要がある。これは、小さすぎるインタフェース伝送レートによって阻害されてはならない。
【００１７】
再び、ＭＭＣ−４ Ｗｒｉｔｅ（１２）コマンドなどの書き込み状態においてストリーミング伝送の実行が必要とされることをロジカルユニットに通知するのに利用可能な各種コマンドが多数存在する。
【００１８】
図３ａはまた、ライト処理中における時間の関数としてバッファ空き量の表示として利用することが可能である。すなわち、書き込み中、バッファ空き量は、データ伝送がドライブユニットを用いてアプリケーションにより開始される閾値又はトリガー値に達するまで低下する。データ伝送は、第２閾値に達するまでバッファ空き量を徐々に増大させる。アプリケーションプログラムは、第２閾値到達後、データ伝送を要求することを停止する。これは、ドライブユニットが自律的処理を開始することが可能となるポイントである。それは、リカバリ又はキャリブレーションが取得するタイマーの値と時間量から、それが息つく時間（ｔｉｍｅ ｔｏ ｂｒｅａｔｈ）を有していることしか知らない。
【００１９】
通常、自律的な非データ伝送処理に利用可能な時間に関する情報は、コマンドを用いてホスト１０６／２０６からドライブユニット１０１／２０１に通信されるべきである。好ましくは、このようなコマンドは、
・初期的なストリームタイミング値（ＩＳＴＶ）
・伝送ユニットサイズ（ＴＵＳ）
・伝送ユニットインクリメント（ＴＵＩ）
・リード又はライト処理が所望されるか示すライトフラグ
の４つのパラメータを含むであろう。
【００２０】
これらは、どのようにパラメータが設定されるかの単なる具体例である。当業者は、他のパラメータを創出するかもしれない。例えば、タイミング値を送信するのでなく、アプリケーションは、ストリーミングバッファにすでにあるデータ量の数量とデータ利用レートを送信するかもしれない。これらの値から、ドライブユニットは、残りの時間を計算することが可能である。利用レートは、ＴＵＳ／ＴＵＩとみなすことが可能である。
【００２１】
図７は、データ伝送のためドライブユニットにおいて動作するフォアグラウンドプロセスの一例を示す。まず７０１において、ドライブユニットは、ホストユニットから上記列挙されたようなタイムアウトパラメータを受け取る。その後７０２において、ドライブユニットはこれらのパラメータを格納する。その後７０３において、ドライブユニットは、タイムアウトカウンタをスタートする。
【００２２】
タイマーは、連続的にカウントダウンする。ドライブがライトフラグにより決定される方向にサイズＴＵＳのデータ量を伝送する毎に、ドライブはＴＵＩを実際のカウンタ値に加えるようにしてもよい。このことは、時間の関数としてタイマーの値をグラフ化した図３ｂに示される。この場合、カウンタ値の増加は、ジグザグのラインに従う。ＴＵＩの追加は、伝送ユニットの伝送の終わりまでタイマー値を増加させるが、この同じ伝送中にタイマー値を低下させる。従って、タイマー値は、ストリーミングバッファの値のジグザグの近似又は推定となる。
【００２３】
図８は、ドライブユニットにおいてリードリクエストが動作する第２のフォアグラウンドプロセスを示す。８０１において、ドライブユニットはリードリクエストを受け取る。８０２においてリードコマンドが、Ｒｅａｄ（１０）などストリーミングを要求しない場合、当該コマンドは、８０３におけるストリーミング要求なしに処理される。８０２においてリードコマンドが、Ｒｅａｄ（１２）などのストリーミングを要求する場合、当該プロセスは、タイマーが経過したか８０６においてテストする。そうである場合、当該コマンドは、８０５においてエラーにより終了する。そうでない場合、当該プロセスは、８０７においてすべてのデータが伝送されたかテストする。そうである場合、当該コマンドは、８０９において良好に終了する。そうでない場合、８０８において、バックグラウンドプロセスからのデータを待機することが可能である。８１０において、利用可能なデータが伝送され、その後８１１において、タイマーが更新される。その後、コントロールは８０６に戻る。
【００２４】
バックグラウンドプロセスファンクション８０８からのデータ待機は、データがバックグラウンドプロセスによってディスクからすでにフェッチされている場合には、極めて迅速にリターンするかもしれない。そうでない場合、フォアグラウンドプロセスは、データが利用可能になるとすぐに、バックグラウンドプロセスによってトリガーされる。もちろん、致命的なエラーが発生する可能性があるが、これはフローチャートには示されていない。
【００２５】
ストリーミング要求なしにコマンドを処理する間、タイマーは依然としてカウントダウンする。なぜなら、コンシューマはアプリケーションのストリームバッファからのデータを依然として利用しているためである。
【００２６】
また、ドライブユニットがリード処理中に媒体に不具合を検出し、リカバリ及び／又はキャリブレーションを実行する実用があると仮定する。この質問は、「コンシューマに対するリアルタイム要求を危険にさらすことなく、このリカバリ処理にドライブがどのくらいの時間費やすことが許されるか」というものである。その回答は、実際には、アプリケーションバッファの充填量に依存する。当該バッファがデータにより充填されている限り、ドライブはそれのリカバリを継続することが可能である。しかしながら、バッファ占有がゼロに接近しているとき、ドライブのリカバリは停止される必要がある。
【００２７】
一般に、インタフェースがこれをサポートしないため、アプリケーションはリカバリを停止することができない。この結果、ドライブユニットは、それのローカルタイマーのタイムアウト値がある閾値に到達すると、自らリカバリを停止しなければならない。しばしば、ドライブユニットは、自律的処理を実行している間にホストに提供可能なキャッシュ１０８と呼ばれるバッファ自体を有するであろう。これは、自律的処理に対するビットにより多くの時間を与えるかもしれないが、ドライブユニットのバッファはストリーミングバッファと比較して一般に小さいものであるため、この余分な時間は重要ではないかもしれない。
【００２８】
図９は、ボックス８０８により利用されるバックグラウンドリードプロセスの一例を示す。当該プロセスは、キャリブレーションと呼ばれる非データ伝送処理を実行しようとするものである。読み込みの際、ドライブはプリフェッチ処理と呼ばれるタスクを実行する。このことは、バックグラウンドプロセスが、さらに（連続するデータ）アプリケーションからの以降のリクエストを予想することができるように、ドライバのバッファがフルになるまで、ディスクからのデータの読み込みを継続することを意味する。これは、ループにおいて行われているものであり、フォアグラウンドプロセスをトリガーした後、バックグラウンドプロセスがデータを読み込み、又は非データ伝送処理を実行し続ける（ドライブユニットにより内部的に要求される場合）ことが可能であり、これにより、そのような処理は、好ましくはバックグラウンドプロセスにおいて実行される。
【００２９】
９０１において、バックグラウンドは、データをドライブユニットのバッファにプリフェッチする。その後９０２において、それはデータが利用可能であるかチェックする。
【００３０】
そうである場合、９０７において、それはフォアグラウンドプロセスをトリガーする。そうでない場合、当該プロセスは、キャリブレーションが９０３において保留中であるか判断する。そうでない場合、９０６において、データはドライブからバッファに伝送され、フォアグラウンドプロセスが９０７においてトリガーされる。
【００３１】
キャリブレーションが保留中である場合、バックグラウンドプロセスは、９０４においてタイムアウトカウンタが非データ伝送処理に対して十分であるかテストする。そうである場合、非データ伝送処理、この場合にはキャリブレーションリクエストが、９０５において実行され、コントロールが９０６にわたされる。非データ伝送処理の時間がない場合、コントロールは、９０５を通過して９０６に直接わたされる。
【００３２】
図７〜９のフローチャートは、パラレルに実行されるべきである。
【００３３】
図４ａ及び４ｂは、エラーの場合における本発明による自律的処理を要求するリード処理のためのフローチャートの一例を示す。
【００３４】
４０１において、ホストは、ＩＳＴＶ、ＴＵＳ、ＴＵＩ及びＷＲＩＴＥパラメータを計算し、その最後はフラグである。その後４０２において、ホストは、後述されるようなセットストリーミングコマンドの「ストリームタイミング記述子」を介しこれらのパラメータを送信する。ドライブは、セットストリーミングコマンドを受け取り、４０３においてストリームタイミング記述子からこれらのパラメータを取得する。その後４０４において、ドライブは、ＩＳＴＶによるダウンカウンタをプログラムし、その他のパラメータを格納する。ここで、ホストは、４０５においてＲｅａｄ（１２）などの少なくとも１つのリードコマンドを送信し、ドライブは、４０６においてリードコマンドを受け取る。フローチャートコネクタＸは、図４ａと４ｂとの間の実行のフローを接続するのに利用される。４１０において、ドライブはディスクから１以上のセクタを読み取る。ドライブユニットがまたバッファを有する場合、データはすでに利用可能であるかもしれない。
【００３５】
その読み込み中、４１１において、ドライブユニットによっていくつかのエラーが検出されるかもしれない。そうである場合、ドライブは、４１８において自律的リードリカバリ処理を実行しなければならない。まず、ドライブは、４２３において自律的処理を実行するのに十分な時間があるかテストする。十分な時間がない場合、ドライブは、４２１においてコネクタＷを介しエラーメッセージを生成する。十分な時間がある場合、コントロールはボックス４１８にわたされる。これらの処理の実行中、ドライブはまた、カウントダウンカウンタ／タイマーをモニタする必要がある。４１９において、カウントダウンがゼロに達する場合、４２２において当該リードはタイムアウトとなる。４２０において、カウントダウンがゼロに到達しないが、リードリカバリが成功しない場合、当該リードは、４２１においてリカバリ不可能なエラーにより終了する必要がある。
【００３６】
４２０において、リードリカバリが成功した場合、ドライブは、４１２において利用可能なデータを示し、それはまた、４１１においてエラーがない場合には、その結果となる。その後、図３ｂに示されるように、ホストは４１２においてドライブからホストにデータを伝送することが可能であり、ドライブは４１４においてダウンカウンタを更新する。ダウンカウンタのこの更新は、フレキシブルなタイムアウトを実現する。ドライブのダウンカウンタが４１５においてゼロに到達する場合、リードタイムアウトがまた実行され、４２２においてリードの終了が不成功となる。ドライブのダウンカウンタが４１５においてゼロに到達しない場合、ドライブは、要求されたすべてのデータが４１６において伝送されたかテストする。そうでない場合、コントロールはボックス４１０に戻る。そうである場合、ドライブは、伝送コマンドが４１７において成功したことを通知する。
【００３７】
図５ａ及び５ｂは、本発明による自律的処理を要求するライト処理のためのフローチャートの一例を示す。
【００３８】
５０１において、ホストは、ＩＳＴＶ、ＴＵＳ、ＴＵＩ及びＷＲＩＴＥパラメータを計算し、その最後がフラグとなる。その後５０２において、ホストは、セットストリーミングコマンドにおいて「ストリームタイミング記述子」を介しパラメータを送信する。ドライブは、５０３において、セットストリーミングコマンドを受け取り、ストリームタイミング記述子からパラメータを取得する。その後５０４において、ドライブは、ＩＳＴＶによりダウンカウンタをプログラムし、その他のパラメータを格納する。ホストは、５０５において少なくとも１つのライトコマンドを送信し、ドライブは、５０６においてライトコマンドを受け取る。５０７において、ドライブは、ホストからデータをリクエストする。その後、ホストは、５０８において１以上のデータブロックをドライブに送信し、５０９において、ドライブはそれを受け付ける。コネクタＹ及びＺが、図５ａ及び５ｂのフローチャート部分を接続するのに利用される。５１０において、ドライブは、ダウンカウンタ、すなわち、タイマーを更新し、これにより、フレキシブルなタイムアウトを実現する。
【００３９】
ダウンカウンタが５１１においてゼロに到達した場合、ライトコマンドは、５２０において、タイムアウト状態により終了する。そうでない場合、ドライブは５１２において、ディスクに書き込みを行う。５１３において、この書き込みによるエラーが検出されると、ドライブは、５１６において自律的なライトリカバリを実行しなければならない。まず、ドライブは５２２において、自律的処理を実行するための時間があるかテストする必要がある。時間がない場合には、５１９において、コネクタＶを介しリカバリ不可能なエラーが生ずる。時間がある場合には、コントロールはボックス５１６にわたされる。ライトリカバリ期間中、ドライブはまた、５１７においてカウントダウンをモニタしなければならない。ドライブのカウントダウンが５１７においてゼロに到達すると、ライトコマンドは、５２０においてタイムアウト状態により終了しなければならない。そうでない場合には、ドライブは、ライトリカバリが５１８において成功したかテストする。不成功であった場合、ライトコマンドは、５１９においてリカバリ不可能なエラーにより終了される。ライトリカバリが成功した場合、コントロールはボックス５１４にわたされ、それはまた、５１３においてエラーが検出されていなければ、コントロールがわたされたであろう場合である。
【００４０】
５１４において、ドライブは、関連するすべてのデータが伝送されたかテストする。そうでない場合、コントロールはブロック５０７に戻る。そうである場合、ドライブは、伝送コマンドが５２１において成功したと判断する。
【００４１】
処理５１９、５２０、５２１、４１７、４２１及び４２２のすべては、ドライブがデータ伝送処理の結果に関する通知をホストに提供することを要求する。
【００４２】
図４ａ、４ｂ、５ａ及び５ｂのフローチャートは、シーケンシャルタイプフォーマットにより書かれているが、それらはまた、図７〜９と同様に、パラレルタイプフォーマットにより設定することが可能である。
【００４３】
ドライブユニットは、レイヤジャンプ、熱管理動作又はリトライなどの他の自律的処理を実行するかもしれない。一般に、自律的処理は、例えば、ドライブ機構又はデータ記憶媒体の物理的メンテナンス又はドライブ機構と記憶媒体との間の相対的ポジショニングのカテゴリなど、各種タイプを有するかもしれない。
【００４４】
何れのケースでも、当該タイプの自律的処理は、ホストに透過であるべきである。コマンドを処理しているフォアグラウンドプロセスは、ドライブユニットのキャッシュにデータが到着することを待機するだけである。それは、データが到着することを待機している理由は知らず、知る必要もない。
【００４５】
当業者は、図４ａ及びｂ並びに図５ａ及びｂと同様又は図７〜９と同様の他の実現形態を、特にボックス４１０、４１１、４１８、５１２、５１３及び５１６に対する若干の修正により上記及び他のタイプの自律的処理のため創出することが可能である。
【００４６】
レイヤジャンプの場合、リード中において、それはボックス４１０の一部として実行することが可能である。レイヤジャンプは、記憶媒体に対する動きの一例である。ディスクからセクタを読み取ることは、光学ヘッドは適切な位置に移動されることを要求する。これは、他のレイヤ上にあるかもしれず、そのためレイヤジャンプと呼ばれる。
【００４７】
フローチャートは、ストリーミングバッファ上のタイムアウトの場合に、永続的に終了する自律的処理を示す。しかしながら、いくつかの自律的処理は十分重要であるため、タイムアウトがあったとしても、それらが進行すべきである。例えば、熱管理処理は、記憶媒体への損害を回避するのに十分な時間がなくても必要であるかもしれない。このような場合、タイムアウトエラーメッセージは、熱管理動作の後に又はそれとパラレルに発行することが可能である。
【００４８】
ボックス５２２及び４２３は、ストリーミングのロスまでの時間が自律的処理を実行するのに必要な時間より大きいか判断する必要がある。以下のテーブルにおいて、ストリーミングのロスまでの時間に関する計算例が示される。
【００４９】
【表１】
ただし、
・Ｃは、Ｋ秒より少なくない期間に試用されるバイトグループ数であり、
・Ｎは、好適なリード又はライトサイズを生成するためＣと乗算可能な乗数であり、
・Ｘは、予め決定されたストリームバッファ充填ポイントである。
【００５０】
一般に、本発明による及びロジカルユニットにおける自律的処理は、コマンド実行中又はコマンド間において実行されるかもしれない。
【００５１】
「コマンド実行中」とは、フローチャートに記載された状況であり。本発明は、ＭＭＣ４からの固定されたタイムアウトに関する基本的問題を解決する。アプリケーションはタイムアウトが指定されることを可能にする。しかしながら、このタイムアウトは、宅コマンドの実行に適用され、従って、これは各コマンドの到着において再開される固定されたタイムアウトである。この定義による問題は、複数のコマンドのタイムアウトを加えることができないということである。本発明のタイムアウトは、実際にはプロセスのタイムアウトであり、単一のコマンドのものではなく、すなわち、フレキシブル又はランニングタイムアウトである。
【００５２】
他の実施例では、コマンド実行中、ドライブは自律的処理がどれくらい重要であるかテストすることが可能であり、その後、データ伝送コマンドの終了前に当該処理が実際にすぐに必要とされる場合には、自律的処理のみをスタートする。他の実施例では、ドライブユニットは、自律的処理に費やすことが可能な時間に関する制限を確立することが可能である。
【００５３】
本発明はまた、コマンド間において利用可能である。これらの状況では、ドライブは、データ伝送以外の動作を自律的かつ安全に実行することが可能である。本発明のタイマー値は、単一のコマンドでなくプロセスに対するランニングタイマーである。従って、バックグラウンドで非データ伝送処理を実行しながら、ドライブは依然として、ストリーミング要求に関する新たな情報を受け取ることが可能であり、コマンド処理はフォアグラウンドタスクとなる。
【００５４】
本発明により維持されるタイムアウト値は、コンシューマへの実際の伝送レートが可変である場合（圧縮により）、不正確なものとなるかもしれない。従って、アプリケーションは、タイマー値を定期的に更新する必要がある。
【００５５】
イニシエータは、かなり多数のセクタが伝送される必要がある１つのコマンドを発行するかもしれないが、少数のセクタにより多数のコマンドを発行するかもしれない。前者のケースでは、非データ伝送処理はコマンドの実行中に行うことが可能であり、後者のケースでは、非データ伝送処理はまた、適切なタイマー値がドライブユニットに伝送し続けられる限り、コマンド間で行われるかもしれない。ドライブユニットがまたキャッシュを有するため、それは、非データ伝送処理をパラレルに実行しながら（リトライ、エラーリカバリ、キャリブレーションなどと同様に）、キャッシュからのこれら多数のコマンドのいくつかに対するセクタを伝送することが可能であるかもしれない。
【００５６】
しかしながら、「コマンド実行中」とは、ドライブが記憶媒体に対するデータの読み書きとパラレルに非データ処理を必然的に実行可能であることを意味するものでないということに留意すべきである。ドライブは単に、本発明のタイミング計算を利用して、記憶媒体への実際のデータアクセスが不要となる時間を活用する。
【００５７】
図６は、リード処理中の経過時間の関数としてのバッファ充填量のグラフを示す。同様のグラフが、ライト処理に適用されるであろう。６０１において、バッファ充填量は、ジャンプバックレベル６０３に到達する。これは、リード処理に対するトリガーとして利用される。第１期間６０４の期間中、データ伝送が実際に開始されるまで、充填量は低下し続ける。参照番号６０５は、データ伝送が行われない場合のタイムアウトまでの期間を示す。参照番号６０６は、フローチャートの４２２において示される状態Ｃのバッファ充填量が続く、すなわち、自律的処理が長くかかりすぎた場合を示す。参照番号６０７及び６０８は、タイミング図のブランチＡ及びＢに対する期間を参照する。これらのブランチは共に、ブロック４１７毎に成功した読み込みに関するが、ブランチＡでは、バッファ充填量はジャンプバックレベル以下には低下せず、ブランチＢでは、バッファ充填量はタイムアウトを生じさせることなく、ジャンプバックレベル以下に低下する。
【００５８】
ホストユニットとドライブとの間で送信されるコマンドは、ＭＭＣ−４規格に見つけられるものなどのフォーマットによるものであってもよく、その草案は、ｈｔｔｐ：／／ｗｗｗ．ｔ１０．ｏｒｇ／ｆｔｐ／ｔ１０／ｄｒａｆｔｓ／ｍｍｃ４／ｍｍｃ４ｒ０３．ｐｄｆに存在する。好適な実施例は、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドを利用して、本発明に関するパラメータをわたす。当業者は、例えば、既存のコマンド又は新しいコマンドを含む他のＭＭＣタイプコマンドを利用することによって、他の通信技術を創出することが可能である。
【００５９】
以下において、本発明を実現するためのＭＭＣタイプ状況における利用に適したコマンドフォーマットが記載される。これらは単なる具体例である。当業者は、本発明が機能する他のフォーマット又はコマンドの利用を創出するかもしれない。
【００６０】
イニシエータは、プロファイル及びフィーチャに関するドライブユニットのすべての機能を取得するため、“ＧＥＴ ＣＯＮＦＩＧＵＲＡＴＩＯＮ”コマンドを発行する。搭載されている媒体に依存して、一部のプロファイル及びフィーチャは現在のものとされる。
【００６１】
プロファイルの現在性は、ドライブユニットによりサポートされるフィーチャのベースセットを規定する。さらに、あるフィーチャは、ドライブユニットの機能及び動作を指定するコマンド及びモードページセットを記述する。
【００６２】
テーブル２において、イニシエータに返されるべきリアルタイムストリーミングフィーチャに対するフィーチャ記述子レスポンスデータが規定される。
【００６３】
【表２】
これの大部分は、“Ｓｔｒｅａｍｅｄ Ｔｉｍｉｎｇ（ＳＴ）”ビットが追加されることを除いて、ＭＭＣ−４規格に従っている。当該ビットが１である場合、それは、当該ロジカルユニットが“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドの“Ｓｔｒｅａｍｅｄ Ｔｉｍｉｎｇ”記述子をサポートしていることを示す。
【００６４】
このフィーチャをサポートするロジカルユニットは、テーブル３に列挙されるコマンドを実現する。
【００６５】
【表３】
［ＳＥＴ ＳＴＲＥＡＭＩＮＧコマンド］
ステップ４０２及び５０２は、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドを利用して、“Ｓｔｒｅａｍ Ｔｉｍｉｎｇ”記述子をドライブユニットに送信することに関する。
【００６６】
“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドは、イニシエータにデータレートに対する要求を通信する方法を提供する。実行設定は永続的なものであり、新たな記述子が送信されるまで残る。
【００６７】
“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドが実行設定に利用される場合、ロジカルユニットは、実行基準を満たすため、指定された領域におけるリード及びライト再割当てを不可とするかもしれない。
【００６８】
テーブル４は、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドに係るフィーチャを示す。
【００６９】
【表４】
［ＣＤＢ及びそれのパラメータ］
テーブル５において、“ＳＥＴ ＳＴＲＥＡＭＩＮＧ ＣＤＢ”が示される。
【００７０】
【表５】
［タイプ］
タイプフィールド（テーブル６）は、何れのタイプのデータが伝送されるか示している。
【００７１】
【表６】
このテーブルは、パフォーマンス記述子（ＭＭＣ−４に存在する）、ストリームタイミング記述子及びＤＢＩキャッシュゾーン記述子（ＭＭＣ−４に存在する）のおそらく送信可能な３つの記述子を記載している。
［コマンド実行］
“ＳＥＴ ＳＴＲＥＡＭＩＮＧ”コマンドは、アプリケーションがロジカルユニットの実行の対する具体的リクエスト又は要求を有していることをイニシエータがロジカルユニットに示す方法を提供する。
［ストリームタイミング記述子］
以下のテーブル７の特にバイト４〜１５のストリームタイミング記述子は、イニシエータ及びロジカルユニットがストリームの連続性を維持するためにタイミング情報を共有することを可能にする。
【００７２】
ロジカルユニットは、ストリームメンテナンスに利用可能な時間を表す利用可能タイマーを維持する。利用可能タイマーは、カウントダウンタイマーである。ストリームタイミングがイネーブルとされ、利用可能タイマーがゼロに達すると、ストリーミング“ＵＮＩＴ ＡＴＴＥＮＴＩＯＮ”状態のロスが存在する。
【００７３】
【表７】
［イネーブル］
イネーブルがゼロに設定されると、ストリームタイミング記述子に基づく現在アクティブなすべてのストリームタイミングファンクションが不可とされる。イネーブルが１に設定されると、ストリームタイミングは、含んでいる記述子のパラメータに従ってイネーブルとされる。
［ライト］
イネーブルが１に設定され、ライトがゼロに設定されると、読み出しのためのストリーミングタイミングファンクションがイネーブルとされ、リードのためのストリーミングタイミングが、当該記述子のパラメータに従って初期化される。
【００７４】
イネーブルが１に設定され、ライトが１に設定されると、書き込みのためのストリームタイミングファンクションはイネーブルとされ、ライトのためのストリームタイミングは、当該記述子のパラメータに従って初期化される。
【００７５】
イネーブルがゼロに設定されるときは常に、ライトビットは規定されない。
［ストリームタイミング初期値］
ストリームタイミング初期値は、ストリーミング“ＵＮＩＴ ＡＴＴＥＮＴＩＯＮ”状態のロスが存在するまでのミリ秒数を表す。
【００７６】
イネーブルが１に設定されると、ロジカルユニットは、それの利用可能時間タイマーをストリームタイミング初期値に初期化し、利用可能タイマーをスタートする。
【００７７】
イネーブルがゼロに設定されているときは常に、当該パラメータは規定されない。
［伝送ユニットサイズ］
伝送ユニットサイズは、伝送毎の好適なセクタ数である。
［伝送ユニットインクリメント］
伝送ユニットインクリメントは、伝送ユニットサイズセクタが伝送された後、利用可能時間タイマーに加えられるミリ秒数である。
【００７８】
本開示を参照することから、当業者には他の改良が明らかになるであろう。このような改良は、イニシエータとロジカルユニットの間のデータ伝送のための装置の設計、製造及び利用についてすでに知られ、ここですでに記載された特徴の代わりに、又はそれに加えて利用可能な他の特徴に関するものであるかもしれない。本出願では、特定の特徴の組み合わせにタイする請求項が記載されているが、本出願の開示の範囲はまた、本発明と同一の技術的問題の何れか又はすべてを軽減するか否に関係なく、明示的又は非明示的にここで開示されている新規な特徴又は新規な特徴の組み合わせ又はそれの何れかの一般化を含む。本出願人は、本出願又はそれから派生するさらなる出願の手続において、新たな請求項がそのような特徴に規定されるということを通知する。
【００７９】
ここで使用される「有する」という用語は、さらなる要素を排除するものとしてみなされるものではない。ここで使用される単数形の冠詞「ある」は、複数の要素を排除するものとしてみなされるものではない。
【符号の説明】
【００８０】
１０１ データソース
１０４ ロジカルユニット
１０６ ホスト
１０７ 媒体
【特許請求の範囲】
【請求項１】
ストリーミングのロス前の時間に関するデータアイテムを含む情報をドライブユニットに伝送するよう構成されるコマンドを含むコマンドセットを利用するよう構成される少なくとも１つのホストユニットと、
前記コマンドを受け付け、前記データアイテムからストリーミングのロス前の利用可能な時間を求め、前記ストリーミングのロス前の利用可能な時間に基づき、フレキシブルなタイムアウトに従って自己の処理を調整するよう構成される少なくとも１つのドライブユニットと、
を有することを特徴とするデータプロセッシングシステム。
【請求項２】
少なくとも１つのホストユニットからデータ伝送リクエストを受け付ける手段と、
少なくとも１つの記憶媒体にアクセスする手段と、
データ伝送リクエストに関するコマンドパラメータを受付及び格納し、ストリーミングの実行の要求を識別し、ストリーミングのロス前に残された時間を決定し、前記残された時間に従って自律的非データ伝送処理を調整するよう構成されるローカルプロセッシング機能と、
を有することを特徴とするドライブユニット。
【請求項１】
ストリーミングのロス前の時間に関するデータアイテムを含む情報をドライブユニットに伝送するよう構成されるコマンドを含むコマンドセットを利用するよう構成される少なくとも１つのホストユニットと、
前記コマンドを受け付け、前記データアイテムからストリーミングのロス前の利用可能な時間を求め、前記ストリーミングのロス前の利用可能な時間に基づき、フレキシブルなタイムアウトに従って自己の処理を調整するよう構成される少なくとも１つのドライブユニットと、
を有することを特徴とするデータプロセッシングシステム。
【請求項２】
少なくとも１つのホストユニットからデータ伝送リクエストを受け付ける手段と、
少なくとも１つの記憶媒体にアクセスする手段と、
データ伝送リクエストに関するコマンドパラメータを受付及び格納し、ストリーミングの実行の要求を識別し、ストリーミングのロス前に残された時間を決定し、前記残された時間に従って自律的非データ伝送処理を調整するよう構成されるローカルプロセッシング機能と、
を有することを特徴とするドライブユニット。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３Ａ】
【図３Ｂ】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１１−２１６１０２（Ｐ２０１１−２１６１０２Ａ）
【公開日】平成２３年１０月２７日（２０１１．１０．２７）
【国際特許分類】
【出願番号】特願２０１１−１２８０７３（Ｐ２０１１−１２８０７３）
【出願日】平成２３年６月８日（２０１１．６．８）
【分割の表示】特願２００７−５２２１００（Ｐ２００７−５２２１００）の分割
【原出願日】平成１７年７月１８日（２００５．７．１８）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公開日】平成２３年１０月２７日（２０１１．１０．２７）
【国際特許分類】
【出願日】平成２３年６月８日（２０１１．６．８）
【分割の表示】特願２００７−５２２１００（Ｐ２００７−５２２１００）の分割
【原出願日】平成１７年７月１８日（２００５．７．１８）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]