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