電力管理のための下流デバイスのサービス待ち時間報告
【課題】電池式のモバイルデバイスおよびシステムの電力管理により拡張動作を可能とする。
【解決手段】パーソナルコンピュータでは、第1の状態から第2の状態への下流デバイスの少なくとも一部の遷移を特定することができる。第1の状態および第2の状態は、下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応していてよい。特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせることができる。
【解決手段】パーソナルコンピュータでは、第1の状態から第2の状態への下流デバイスの少なくとも一部の遷移を特定することができる。第1の状態および第2の状態は、下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応していてよい。特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせることができる。
【発明の詳細な説明】
【技術分野】
【0001】
開示する実施形態は、概して電力管理に係る。
【背景技術】
【0002】
多くのデバイスおよびシステムで、電力効率を向上させるために電力管理が行われており、消費電力および/または放熱量の低減の一助となっている。電池式のモバイルデバイスおよびシステムでは、電力管理により拡張動作が可能となる。
【0003】
プラットフォームレベルの電力管理は、プラットフォームで収集された発見およびオペレーティングシステムからのガイダンスに基づいてきた。プロセッサ利用率は、プラットフォームアクティビティの概算として利用することができる。しかしながら、入出力(I/O)アクティビティが重く、プロセッサ利用率が軽い場合には、プラットフォームは低電力状態となり、I/O性能に影響が出る。実際のところ、プラットフォームが深い電力状態に入ると、直接メモリアクセス(DMA)アクセスおよび中断等のイベントを起こす際の応答待ち時間が増加する。多くのI/Oデバイスは、プラットフォームからの幾らかの固定最小応答待ち時間を許容するように設計されてはいるものの、これによって、プラットフォームが入ることのできる電力状態の深さには効果的に制限が加わりうる。プラットフォームが、その応答待ち時間がI/Oデバイスが許容可能な固定最小値よりも増加した深い電力状態に入ると、プラットフォームの機能および/または性能は危険に曝される。
【図面の簡単な説明】
【0004】
実施形態を例示として示し、添付図面による限定は意図されないが、添付図面において、同様の参照符号は同様の部材を示す。
【0005】
【図1】一実施形態において、1以上の下流デバイスからのサービス待ち時間報告に少なくとも部分的に基づいて電力管理を行う例示的なシステムのブロック図を示す。
【0006】
【図2】一実施形態において、上流デバイスへサービス待ち時間を報告する下流デバイスの例示的なブロック図を示す。
【0007】
【図3】一実施形態において、下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0008】
【図4】一実施形態において、第1の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0009】
【図5】一実施形態において、第1の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0010】
【図6】一実施形態において、第2の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0011】
【図7】一実施形態において、第2の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0012】
【図8】一実施形態において、第2の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。
【0013】
【図9】一実施形態において、第3の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0014】
【図10】一実施形態において、第3の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0015】
【図11】一実施形態において、第3の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。
【0016】
【図12】一実施形態において、第4の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0017】
【図13】一実施形態において、第5の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0018】
【図14】一実施形態において、第5の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0019】
【図15】一実施形態において、第6の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0020】
【図16】一実施形態において、第6の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0021】
【図17】一実施形態において、第6の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスの例示的な図を示す。
【0022】
図面は、必ずしも実寸に即して描かれていない場合がある。
【発明を実施するための形態】
【0023】
以下の詳細な記載は、電力管理のための下流デバイスのサービス待ち時間報告に関する装置、方法、およびシステムの例示的な実施形態に関する。例えば構造、機能、および/または特性等の特徴は、便宜上、一実施形態に関して示されているが、記載された特徴のうち適切な1以上のものを利用して様々な実施形態を実装することができる。
【0024】
図1は、1以上のプロセッサ110と、プロセッサ110に連結されたプラットフォーム制御ロジック120とを含む例示的なシステム100を示す。一実施形態のプロセッサ110は、1以上のプロセッサ電力管理コントローラ(PPMC)112を含み、プロセッサ110の電力効率を高めることができる。一実施形態のプラットフォーム制御ロジック120は、プラットフォームコントローラ電力管理コントローラ(PCPMC)122を含み、システム100の電力効率を高めることができる。例えば一実施形態のPCPMC122は、システム100の1以上のコンポーネントを、コンポーネントがあまりアクティブではないとき、またはアイドルのとき、複数の低電力状態またはスリープ状態のうち1つに移行させるよう管理する。
【0025】
一実施形態のPCPMC122は、システム100のコンポーネントの電力管理を調整して、電力効率を高めることができる。一実施形態のPCPMC122は、例えば、1位以上のPPMC112の間の調整を行い、これらPPMC112およびPCPMC122に、1以上のコンポーネントに関して、機能および/または性能の低下に対する懸念なく他の1以上のコンポーネントに対して応答する能力を維持できるような低電力状態の深さをより適切に特定することができる。
【0026】
一実施形態のPCPMC122は、例えばデバイス132等の1以上の下流デバイスから、そのデバイスのサービス待ち時間に対応するデータを受信してよい。一実施形態のPCPMC122は、受信データに少なくとも部分的に基づいて(故に、対応するサービス待ち時間に少なくとも部分的に基づいて)電力管理を行うことができる。一実施形態のサービス待ち時間は、そのデバイスのサービス待ち時間の許容範囲であってもよい。一実施形態のサービス待ち時間は、そのデバイスがデバイスの機能または性能に悪影響を与えずに許容できる最大待ち時間に少なくとも部分的に基づいていてよい。一実施形態のサービス待ち時間は、デバイスの少なくとも一部のアクティビティに関するレベルに対応していてよい。従って一実施形態のPCPMC122は、経時的に、デバイスの少なくとも一部のアクティビティレベルに少なくとも部分的に基づいて、デバイスから異なるサービス待ち時間を受信してよい。一実施形態のPCPMC122は、システム100の1以上のコンポーネントに関して、機能および/または性能の低下に対する懸念なくデバイスに対して応答する能力を維持できるような低電力状態の深さをより適切に特定することができる。
【0027】
一実施形態の1以上のPPMC112は、PCPMC122との間で調整を行い、下流デバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を行ってよい。一実施形態のPCPMC122は、デバイスのサービス待ち時間に対応して受信したデータを、1以上のPPMC112に送り、これらPPMC112に、このサービス待ち時間に少なくとも部分的に基づいて電力管理を行わせてよい。一実施形態の1以上のPPMC112は、このサービス待ち時間に少なくとも部分的に基づいてPCPMC122がどのように電力管理を行うか、に少なくとも部分的に基づくデバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。
【0028】
一実施形態のプラットフォーム制御ロジック120は、例えばデバイス132および134等の1以上のデバイスと通信する1以上のインタフェースコントローラ124を含むことができる。このインタフェースコントローラ124は、任意の適切な方法で1以上のデバイスとインタフェースする任意の適切なロジックを含んでよい。一実施形態の1以上のインタフェースコントローラ124は、例えば任意のユニバーサルシリアルバス(USB)仕様(例えば、USB仕様改訂版2.0、2000年4月27日、USB2.0リンク電力管理補足エンジニアリング変更報告、2007年7月16日、USB3.0仕様改訂版1.0、2008年11月12日)および/または任意の適切なPCI(Peripheral Component Interface)またはPCIエクスプレス(PCIe)仕様(例えば、PCIエクスプレスベース仕様改訂版1.0、2002年7月22日、PCIエクスプレスベース仕様改訂版2.0、2007年1月15日)等であるがこれらに限定されない任意の適切な1以上の標準的な仕様と互換性を有してよい。
【0029】
一実施形態の1以上のインタフェースコントローラ124は、1以上の下流デバイスから、そのデバイスのサービス待ち時間に対応するデータを受信して、このデータをPCPMC122に送信してよい。一実施形態の1以上のインタフェースコントローラ124は、インタフェースコントローラ電力管理コントローラ(ICPMC)126を含み、インタフェースコントローラ124および/または1以上のデバイスへの接続またはリンクのための電力効率を上げることができる。一実施形態の1以上のICPMC126は、1以上のデバイスから、そのデバイスのサービス待ち時間に対応するデータを受信して、この受信データに少なくとも部分的に基づいて、故にこれに対応するサービス待ち時間に少なくとも部分的に基づいて、電力を管理してよい。一実施形態のPCPMC122は、このサービス待ち時間に少なくとも部分的に基づいてICPMC126がどのように電力管理を行うか、に少なくとも部分的に基づくデバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。
【0030】
一実施形態のインタフェースコントローラ124は、例えばデバイス134等の別のデバイスの下流の例えばデバイス136等のデバイスのサービス待ち時間に対応するデータを受信してよい。一実施形態のデバイス134は、デバイス136から、デバイス136のサービス待ち時間に対応するデータを受信して、このデータをインタフェースコントローラ124へ送信してよい。一実施形態のデバイス134は、デバイス136から、デバイス136のサービス待ち時間に対応するデータを受信して、この受信データに少なくとも部分的に基づいて、故にこれに対応するサービス待ち時間に少なくとも部分的に基づいて、デバイス134の電力を管理してよい。一実施形態の対応するICPMC126は、このサービス待ち時間に少なくとも部分的に基づいてデバイス134がどのように電力管理を行うか、に少なくとも部分的に基づくデバイス136のサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。
【0031】
一実施形態では、システム100における電力管理は、次の文献に記載されるデバイスのサービス待ち時間に少なくとも部分的に基づいて行われてよいが、文献は、「LATENCY BASED PLATFORM COORDINATION」なる名称で、2007年12月31日に出願された米国特許出願第12/006,251号、「PLATFORM POWER MANAGEMENT BASED ON LATENCY GUIDANCE」なる名称で、2008年3月31日に出願された米国特許出願第12/059,992、および/または、「COORDINATED LINK POWER MANAGEMENT」なる名称で、2008年6月26日に出願された米国特許出願第12/146,873号である。
【0032】
図1に示すように、一実施形態のシステム100は、さらに、1以上の入力デバイス140、1以上のディスプレイ150、揮発性メモリ160、1以上の不揮発性メモリおよび/または記憶デバイス170、および1以上の通信インタフェース180を有してよい。
【0033】
一実施形態のプロセッサ110は、揮発性メモリ160にインタフェースを提供する1以上のメモリコントローラを含んでよい。揮発性メモリ160は、例えばシステム100にデータおよび/または命令をロードおよび格納するのに利用されてよい。揮発性メモリ160は、適切なダイナミックRAM(DRAM)等の任意の適切な揮発性メモリを含んでよい。一実施形態のプロセッサ110は、PPMC112を利用して揮発性メモリ160の電力管理を助けてよい。
【0034】
プロセッサ110に常駐するとして記載されているが、一実施形態の1以上のメモリコントローラは、プラットフォーム制御ロジック120に常駐することで、プラットフォーム制御ロジック120に、揮発性メモリ160と直接通信させてもよい。
【0035】
一実施形態のプラットフォーム制御ロジック120は、インタフェースコントローラ124を含む任意の適切なインタフェースコントローラを含むことで、プロセッサ110に、および/または、プラットフォーム制御ロジック120と通信する任意の適切なデバイスまたはコンポーネントに、任意の適切な通信リンクを提供してよい。一実施形態のプラットフォーム制御ロジック120は、PCPMC122を利用することで、プラットフォーム制御ロジック120と通信する任意の適切な1以上のデバイスおよび/またはコンポーネントの電力管理を助けてよい。
【0036】
一実施形態のプラットフォーム制御ロジック120は、ディスプレイ150にインタフェースを提供する1以上のグラフィックコントローラを含んでよい。例えば、ディスプレイ150は、陰極線管(CRT)または液晶ディスプレイ(LCD)等の任意の適切なディスプレイを含みうる。一実施形態の1以上のグラフィックコントローラは、プラットフォーム制御ロジック120の外にあってもよい。
【0037】
一実施形態のプラットフォーム制御ロジック120は、1以上の入出力(I/O)コントローラを含むことで、入力デバイス140、不揮発性メモリおよび/または記憶デバイス170、および通信インタフェース180へインタフェースを提供してよい。
【0038】
入力デバイス140は、キーボード、マウス、および/または任意の他の適切なカーソル制御デバイス等の任意の適切な入力デバイスを含みうる。
【0039】
不揮発性メモリおよび/または記憶デバイス170は、例えばデータおよび/または命令を記憶するのに利用されてよい。不揮発性メモリおよび/または記憶デバイス170は、例えばフラッシュメモリ等の任意の適切な不揮発性メモリを含んでよく、および/または、例えば1以上のハードディスクドライブ(HDD)、1以上のコンパクトディスク(CD)ドライブ、および/または、1以上のDVD(デジタル多用途ディスク)ドライブ等の任意の適切な不揮発性記憶デバイスを含んでよい。
【0040】
通信インタフェース180は、1以上のネットワーク上で、および/または、任意の他の適切なデバイスと通信するインタフェースをシステム100に提供してよい。通信インタフェース180は、任意の適切なハードウェアおよび/またはファームウェアを含んでよい。一実施形態の通信インタフェース180は、例えば、ネットワークアダプタ、無線ネットワークアダプタ、電話モデム、および/または、無線モデムを含んでよい。無線通信のために、一実施形態の通信インタフェース180は、1以上のアンテナ182を利用してよい。
【0041】
一実施形態の下流デバイス132、134、および136は、プラットフォーム制御ロジック120に連結されてよい任意の適切なデバイスであってよい(例えば適切な入力デバイス140、適切な不揮発性メモリまたは記憶デバイス170、適切な通信インタフェース180、または任意の他の適切なI/Oデバイス等を含むがこれらに限定されない)。下流デバイスの例には、カーソル制御デバイス、記憶ドライブ、記憶デバイス、ハブデバイス、ネットワークルータまたはスイッチ、充電デバイス、プリンタ、スキャナ、カムコーダ、カメラ、メディアプレーヤ、セルラー式電話機、スマートフォン、モバイルインターネットデバイス、およびデスクトップ、ノートブック、ネットブック等のコンピュータシステム、またはその他のコンピュータシステムが含まれうるが、これらに限定されない。
【0042】
プラットフォーム制御ロジック120に常駐するとして記載したが、1以上のインタフェースコントローラ124を含むプラットフォーム制御ロジック120の1以上のコントローラは、一実施形態では、1以上のプロセッサ110に常駐することで、プロセッサ110を、1以上のデバイスまたはコンポーネントと直接通信させることができる。1以上のインタフェースコントローラ124を含むプラットフォーム制御ロジック120の1以上のコントローラは、一実施形態では、単一のダイの上で、1以上のプロセッサ110の少なくとも一部とともに集積されてもよい。1以上のインタフェースコントローラ124を含むプラットフォーム制御ロジック120の1以上のコントローラは、一実施形態では、1以上のプロセッサ110とともにパッケージされてもよい。<サービス待ち時間の報告>
【0043】
図2は、一実施形態における、1以上の上流デバイスのサービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいて電力を管理するデバイス200を示す。一実施形態のデバイス200は、例えば図1の下流デバイス132または134に対応しており、サービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいてシステム100に電力を管理させる。一実施形態のデバイス200は、例えば図1の下流デバイス136に対応しており、サービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいてデバイス134および/またはシステム100に電力を管理させる。
【0044】
図2に示すように、一実施形態のデバイス200は、デバイス制御ロジック202、インタフェース制御ロジック204、遷移特定ロジック206、およびサービス待ち時間報告ロジック208を含んでよい。デバイス制御ロジック202、インタフェース制御ロジック204、遷移特定ロジック206、およびサービス待ち時間報告ロジック208は、それぞれ、例えば任意の適切なハードウェア、任意の適切なファームウェアを実行する任意の適切なハードウェア、任意の適切なソフトウェアを実行する任意の適切なハードウェア、または、このような実装の任意の適切な組み合わせを利用して、任意の適切な方法で実装することができる。一実施形態では、上述した任意のファームウェアおよび/またはソフトウェアが、デバイス200の任意の適切なコンピュータ可読記憶媒体(1または複数)に記憶されてよい。一実施形態のデバイス200は、さらに、デバイス200の任意の適切な機能を実装する他の適切なロジック、回路、および/または、1以上のコンポーネントを有してよい。
【0045】
一実施形態のデバイス制御ロジック202は、デバイス200の機能の制御を助けてよく、インタフェース制御ロジック204を利用して1以上の上流デバイスを通信してこれらデバイスの1以上のコンポーネントに機能を提供してよい。
【0046】
インタフェース制御ロジック204は、デバイス制御ロジック202に連結されて、任意の適切な方法でデバイス200に対してデータを送受信してよい。一実施形態のインタフェース制御ロジック204は、例えば任意のユニバーサルシリアルバス(USB)仕様および/または任意の適切なPCI(Peripheral Component Interface)またはPCIエクスプレス(PCIe)仕様等であるがこれらに限定されない任意の適切な1以上の標準的な仕様と互換性を有してよい。
【0047】
一実施形態の遷移特定ロジック206は、デバイス200の少なくとも一部の、ある状態から別の異なる状態への遷移を任意の適切な方法で特定してよい。一実施形態でこれらの状態は、デバイス200の少なくとも一部のアクティビティに関するそれぞれ異なるレベルに対応していてよい。一実施形態の遷移特定ロジック206は、デバイス制御ロジック202の少なくとも一部の、ある状態から別の異なる状態への遷移を任意の適切な方法で特定してよい。一実施形態の遷移特定ロジック206は、デバイス200の少なくとも一部が、ある状態から別の異なる状態へ遷移しようとしていることを特定することができる。一実施形態の遷移特定ロジック206は、デバイス200の少なくとも一部が、既にある状態から別の異なる状態へ遷移したことを特定することができる。
【0048】
一実施形態のサービス待ち時間報告ロジック208は、遷移特定ロジック206による遷移の特定に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック208は、任意の適切な方法で遷移特定ロジック206から状態遷移の特定を受信するよう連結されてよい。一実施形態のサービス待ち時間報告ロジック208は、インタフェース制御ロジック204を用いて任意の適切な方法でサービス待ち時間に対応するデータを送信するよう連結されてよい。
【0049】
一実施形態のサービス待ち時間報告ロジック208は、任意の適切な方法でサービス待ち時間を特定してよい。一実施形態のサービス待ち時間は、デバイス200のサービス待ち時間の許容範囲であってもよい。一実施形態のサービス待ち時間は、デバイス200がデバイス200の機能または性能に悪影響を与えずに許容できる最大待ち時間に少なくとも部分的に基づいていてよい。一実施形態のサービス待ち時間は、デバイス200の少なくとも一部の新たな状態に対応していてもよい。
【0050】
一実施形態のサービス待ち時間報告ロジック208は、前のまたは現在のサービス待ち時間および状態遷移の特定に少なくとも部分的に基づいて、新たなサービス待ち時間を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、新たな状態に少なくとも部分的に基づいて新たなサービス待ち時間を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、前のまたは現在の状態に少なくとも部分的に基づいて新たな状態を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、任意の適切な方法で遷移特定ロジック206から新たな状態の特定を受信してよい。
【0051】
デバイス200の少なくとも一部が状態間の遷移を続ける間、一実施形態のサービス待ち時間報告ロジック208は、新たなサービス待ち時間の特定をし続け、これらサービス待ち時間に対応するデータの送信を続けてよい。一実施形態のサービス待ち時間報告ロジック208は、オプションとして、新たなサービス待ち時間に対応するデータを送信しなくてもよい(例えば、新たなサービス待ち時間が、前のまたは現在のサービス待ち時間と同じである場合等)。一実施形態のサービス待ち時間報告ロジック208は、状態間の1以上であるが全てではなくてよい遷移に呼応して、新たなサービス待ち時間に対応するデータを送信してよい。
【0052】
図3は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図300を示す。図3に示すように、デバイス200の少なくとも一部が、ブロック302の第1の状態にあってよい。ブロック304で、サービス待ち時間報告ロジック208は、第1の状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック306で、デバイス200の少なくとも一部が、第2の異なる状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック308で、サービス待ち時間報告ロジック208は、第2の状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック310で、デバイス200の少なくとも一部が、第1の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック304で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック304から310の動作を繰り返してよい。
【0053】
第1および第2の状態に対応する第1および第2のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、2を越える数の状態に対応するサービス待ち時間のデータを送信することもできる。<アクティビティレベルに少なくとも部分的に基づくサービス待ち時間>
【0054】
一実施形態の遷移特定ロジック206は、互いに異なるアクティビティレベルに対応する状態間の、デバイス200の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、より高いアクティビティレベルに対応する状態に遷移するより低いサービス待ち時間に対応するデータを送信してよく、より低いアクティビティレベルに対応する状態に遷移するより高いサービス待ち時間に対応するデータを送信してよい。一実施形態の遷移特定ロジック206は、デバイス200が上流デバイスとの間でデータ通信するアクティブ状態と、デバイス200が上流デバイスとの間でデータ通信しないアイドル状態との間の、デバイス200の少なくとも一部の遷移を特定することができる。
【0055】
一実施形態のデバイス200の少なくとも一部は、たまに頻繁に、異なる状態間を遷移することができる。一例としては、一実施形態のデバイス200の少なくとも一部が、アクティビティバーストを有しているがために、たまに頻繁に、低アクティビティまたはアイドル状態に入退出することができる。一実施形態のサービス待ち時間報告ロジック208は、状態遷移が特定されてから、サービス待ち時間に対応するデータを送信するまで所定の期間を待つことにより、デバイス200の少なくとも一部が新たな状態に留まる可能性が高いか否かを特定する助けをしてよい。このようにして、一実施形態のサービス待ち時間報告ロジック208は、さもなくば1以上の上流デバイスの電力管理の効果を低減させうる、異なるサービス待ち時間に対応するデータの頻繁な送信を避けることができる。
【0056】
一実施形態のサービス待ち時間報告ロジック208は、現在のサービス待ち時間よりも高いサービス待ち時間に対応する状態への遷移が特定されてから、現在のサービス待ち時間より低いサービス待ち時間に対応する状態への遷移が特定されるまでの所定の期間を待ってよい。一例としては、一実施形態のサービス待ち時間報告ロジック208は、低アクティビティまたはアイドル状態への遷移が特定されてから、より高いアクティビティ状態への遷移が特定されるまでの所定の期間を待ってよい。
【0057】
図4に示すように、一実施形態のサービス待ち時間報告ロジック208は、新たな状態遷移の特定の後の待ち時間を特定するためにタイマ402を有してよい。一実施形態のサービス待ち時間報告ロジック208は、この待ち時間を所定の閾値と比較して、待ち時間が所定の閾値以上となるまで、新たな状態遷移のサービス待ち時間に対応するデータの送信を待ってよい。遷移特定ロジック206が所定の閾値に達する前に新たな状態遷移を特定すると、一実施形態のサービス待ち時間報告ロジック208は、この、より新しい遷移用にタイマ402をリセットしてよい。一実施形態のサービス待ち時間報告ロジック208は、この代わりに、例えばより新しい遷移の状態に少なくとも部分的に基づいて、タイマ402をリセットして、より新しい遷移のサービス待ち時間に対応するデータを送信してよい。
【0058】
図5は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図500を示す。図5に示すように、デバイス200の少なくとも一部が、ブロック502の低アクティビティまたはアイドル状態にあってよい。ブロック504で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック506で、デバイス200の少なくとも一部が、より高いアクティビティ状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック508で、サービス待ち時間報告ロジック208は、第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック510で、デバイス200の少なくとも一部が低アクティビティまたはアイドル状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック512で、サービス待ち時間報告ロジック208は、所定の期間待ってよい。ブロック514でデバイス200の少なくとも一部がまだ低アクティビティまたはアイドル状態である場合、ブロック504で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック504から514の動作を繰り返してよい。
【0059】
低アクティビティ/アイドルおよびアクティブ状態に対応するアイドルおよびアクティブのサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、例えば互いに異なるアクティビティレベルに対応する1以上の状態等の1以上のさらなる状態に対応するサービス待ち時間のデータを送信することもできる。<デバイスバッファリングに少なくとも部分的に基づくサービス待ち時間>
【0060】
一実施形態のデバイス200は、上流デバイスへの送信用に別のデバイスからデータを受信してよい。図6に示すように、一実施形態のデバイス制御ロジック202は、任意の適切な通信リンク(任意の適切な無線リンクを含む)を介して別のデバイスからデータを受信するバッファ602を含むことで、インタフェース制御ロジック204を利用してバッファ602から上流デバイスへデータを後で送信することができる。一実施形態のデバイス200は、例えば、イーサネット(登録商標)ネットワークインタフェースコントローラ(NIC)であってよい。
【0061】
デバイス200の少なくとも一部が低アクティビティまたはアイドル状態である一実施形態では、デバイス200は、デバイス200がデータを受信するためのバッファ602の利用可能な容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信する。このようにして、一実施形態の上流デバイスは、サービス待ち時間の間も対応可能である状態を維持して、バッファ602の利用可能な容量が満杯になる前にバッファ602からのデータ受信を開始することができる。サービス待ち時間がこれより高い場合には、上流デバイスは、より深く、より低い電力状態に入ることも考えられ、時を得た応答ができない可能性があり、これによりバッファ602はオーバフローして、性能が低下して、失われたデータを再送信しなければなくなる虞もある。
【0062】
一実施形態の遷移特定ロジック206は、バッファ602にデータを受信して、バッファ602からデータを再送信すべく、低アクティビティまたはアイドル状態からアクティブ状態への遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、その後、より低いサービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック208は、デバイス200がデータを受信するためのバッファ602のリザーブ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。このようにして、デバイス200は、データがバッファ602から上流デバイスへ送信され始めると、バッファ602へのデータの受信を続けることができる。
【0063】
図7は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図700を示す。図7に示すように、デバイス200の少なくとも一部が、ブロック702の低アクティビティまたはアイドル状態にあってよい。ブロック704で、サービス待ち時間報告ロジック208は、利用可能なバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック706で、デバイス200の少なくとも一部が、別のデバイスからのデータを受信または再送信するアクティブ状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック708で、サービス待ち時間報告ロジック208は、リザーブバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック710で、デバイス200の少なくとも一部が、低アクティビティまたはアイドル状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック704で、サービス待ち時間報告ロジック208は、利用可能なバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208は、オプションとして、ブロック710の状態遷移の特定の後、ブロック704のデータ送信まで、所定の期間待つことができる。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック704から710の動作を繰り返してよい。
【0064】
一実施形態のサービス待ち時間報告ロジック208は、上流デバイスがデータを受信する際のデータレートおよび/または性能要件を説明して、ブロック704および708でサービス待ち時間を特定することができる。
【0065】
低アクティビティ/アイドルおよびアクティブ状態に対応するサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、1以上のさらなる状態に対応するサービス待ち時間のデータを送信してよい。一実施形態では、サービス待ち時間報告ロジック208は、デバイス200が別のデバイスからデータを受信しうる異なる範囲のデータレートに対応する状態に対応するサービス待ち時間のデータを送信することができる。一実施形態では、サービス待ち時間報告ロジック208は、上流デバイスがデータを受信する際の異なる性能要件に対応する様々な状態に対応するサービス待ち時間のデータを送信することができる。
【0066】
図8は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。図8に示すように、バッファ602は802でネットワークデータを受信する。ネットワークデータ受信の前に、デバイス200はアイドル状態にあり、バッファ602の利用可能な容量およびネットワークデータがバッファ602に受信されるレートに少なくとも部分的に基づいて500マイクロ秒(μs)のLTR(latency tolerance report)に対応するデータを上流プラットフォームコンポーネントに送信している。デバイス200が初めにネットワークデータを受信する際、デバイス200は、アクティブ状態に遷移する、あるいは、遷移しようとしているところであり、802で、100μsのLTRに対応するデータを上流プラットフォームコンポーネントに送信する。100μsのLTRは、バッファ602のリザーブ容量およびネットワークデータがバッファ602に受信されるレートに少なくとも部分的に基づく。100μsのLTRは、バッファ602がネットワークデータを受信する間である、前の500μsのLTR期間内に有効になる。
【0067】
上流プラットフォームコンポーネントは、804、806、および808で、100μsのLTR内に応答して、バッファ602からデータを受信する。デバイス200が810でのネットワークデータの受信を終了すると、デバイス200はアイドル状態に遷移して、タイムアウトと示されている所定の時間の間、待ち、812で500μsのLTRに対応するデータを上流プラットフォームコンポーネントに送信する。図8に示すように、上流プラットフォームコンポーネントは、バッファ602からのデータ受信の際のLTRおよび応答に少なくとも部分的に基づいて様々な電力状態に入る。<電力状態に少なくとも部分的に基づくサービス待ち時間>
【0068】
一実施形態の遷移特定ロジック206は、互いに異なる電力レベルに対応する状態間の、デバイス200の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、より高い電力状態への遷移用に、より低いサービス待ち時間に対応するデータを送信してよく、より低い電力状態への遷移用に、より高いサービス待ち時間に対応するデータを送信してよい。
【0069】
図9に示すように、一実施形態のデバイス制御ロジック202は、デバイス電力管理コントローラ(DPMC)902を含み、デバイス200の電力効率を向上させることができる。一実施形態のDPMC902は、例えば、あまりアクティブまたはアイドルでない場合、デバイス200の少なくとも一部を、1以上のより低電力またはスリープ状態に入らせるよう管理することができる。
【0070】
図10は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図1000を示す。図10に示すように、デバイス200の少なくとも一部が、ブロック1002の低電力状態にあってよい。ブロック1004で、サービス待ち時間報告ロジック208は、低電力状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1006で、デバイス200の少なくとも一部が、より高い電力状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1008で、サービス待ち時間報告ロジック208は、より高い電力状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1010で、デバイス200の少なくとも一部が低電力状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1004で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック1004から1010の動作を繰り返してよい。
【0071】
より低い、および、より高い電力状態に対応する第1および第2のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、2を超える数の電力状態に対応するサービス待ち時間のデータを送信することもできる。
【0072】
図11は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。図11のデバイス200は、例えば、無線ローカルエリアネットワーク(WLAN)デバイスであってよい。図11に示すように、DPMC902は、デバイス200のラジオの電力管理を行い、1102で、低電力またはスリープ状態に入ってよい。一実施形態による図11のデバイス200は、電力管理特徴をサポートする無線プロトコルを利用して、デバイス200に、アクセスポイントまたは基地局に対して、例えばデバイス200が低電力状態に入ろうとしていることを示してよい。このようにすることで、低電力状態にある際にはデバイス200にはデータが送信されない。
【0073】
低電力状態に入る前に、デバイス200は、より高い電力状態にあり、1104で100マイクロ秒(μs)の待ち時間に対応するデータを上流デバイスに送信している。デバイス200が低電力状態に遷移する場合、デバイス200は、1106で1ミリ秒(ms)の待ち時間に対応するデータを上流デバイスに送信する。デバイス200がデータを移動してより高い電力状態に遷移する準備が整っている場合、デバイス200は1108で100μsの待ち時間に対応するデータを上流デバイスに送信する。<タスク実行に少なくとも部分的に基づくサービス待ち時間>
【0074】
一実施形態の遷移特定ロジック206は、互いに異なるタスク実行レベルに対応する状態間の、デバイス200の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、より高いタスク実行状態への遷移用に、より低いサービス待ち時間に対応するデータを送信してよく、より低いタスク実行状態への遷移用に、より高いサービス待ち時間に対応するデータを送信してよい。一実施形態では、より高いタスク実行状態とは、例えば、1以上の係属中のタスクを有する状態に対応していてよい。一実施形態では、より低いタスク実行状態とは、例えば、係属中のタスクがない状態または1以上のタスクが完了した状態に対応していてよい。
【0075】
一実施形態のデバイス制御ロジック202は、デバイス200用に1以上のタスクを実行することができる。一実施形態のデバイス制御ロジック202は、自身で1以上のタスクの実行を開始することもできる。一実施形態のデバイス制御ロジック202は、別のデバイスの要求を受けて1以上のタスクを実行することもできる。一実施形態のデバイス制御ロジック202は、上流デバイスの要求を受けて1以上のタスクを実行することもできる。
【0076】
図12は、一実施形態において、デバイス200が上流デバイスにサービス待ち時間を報告する際の例示的なフロー図1200を示す。図12に示すように、デバイス200の少なくとも一部が、ブロック1202のより低いタスク実行状態にあってよい。ブロック1204で、サービス待ち時間報告ロジック208は、より低いタスク実行状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1206で、デバイス200の少なくとも一部が、より高いタスク実行状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1208で、サービス待ち時間報告ロジック208は、より高いタスク実行状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1210で、デバイス200の少なくとも一部が、より低いタスク実行状態に既に遷移したか、あるいは遷移しようとしているか、特定してよい。特定結果が肯定的である場合、ブロック1204で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック1204から1210の動作を繰り返してよい。
【0077】
より低い、および、より高いタスク実行状態に対応する第1および第2のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、それぞれ異なるタスク実行レベルに対応する2を越える数の状態に対応するサービス待ち時間のデータを送信することもできる。<外部的に制御されるサービス待ち時間>
【0078】
一実施形態のサービス待ち時間報告ロジック208は、上流デバイスが特定したサービス待ち時間に対応するデータを上流デバイスに送信してよい。一実施形態のデバイス200は、例えばデバイス200が厳しくないサービス待ち時間を有していたり、あまり頻繁に変化しないサービス待ち時間を有したりしている場合等に、上流デバイスが特定しうるサービス待ち時間を有してよい。一実施形態のデバイス200は、例えばデバイス200が、上流デバイスが予定する1以上のタスクを行う場合等に、上流デバイスが特定しうるサービス待ち時間を有してよい。一実施形態の上流デバイスは、タスクを予定する前にデバイス200についてより低いサービス待ち時間を特定してよく、全ての予定されていたタスクが完了すると、デバイス200についてより高いサービス待ち時間を特定してよい。
【0079】
一実施形態の上流デバイスは、上流デバイスが特定するサービス待ち時間に対応するデータをデバイス200へ送信してよい。一実施形態の上流デバイスは、デバイス200のサービス待ち時間を特定すべくソフトウェアを実行してよい。一実施形態ではこのようなソフトウェアは、例えば、デバイス200のドライバソフトウェアであってよい。
【0080】
図13に示すように、一実施形態のサービス待ち時間報告ロジック208は、サービス待ち時間に対応するデータを上流デバイスから受信するためのメモリ1302を含んでよい。一実施形態では、メモリ1302の少なくとも一部が、上流デバイスのメモリ空間にマッピングされてよい。一実施形態のメモリ1302は、1以上のレジスタを含んでよい。一実施形態のメモリ1302は、メモリマッピングされた入出力(MMIO)レジスタであってよい。
【0081】
図14は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図1400を示す。図14に示すように、ブロック1402でサービス待ち時間報告ロジック208は、上流デバイスが特定したサービス待ち時間に対応するデータを上流デバイスから受信してよい。一実施形態の上流デバイスは、このデータをソフトウェア実行の際に送信してよい。ブロック1404でサービス待ち時間報告ロジック208は、ブロック1402で受信したデータに少なくとも部分的に基づいてサービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック208は、ブロック1404で、上流デバイスの電力管理コントローラへデータを送信してよい。<定期的な遷移に少なくとも部分的に基づくサービス待ち時間>
【0082】
一実施形態のデバイス200の少なくとも一部は、実質的に固定された時間間隔で、第1の状態から第2の異なる状態へと遷移することができる。一実施形態のデバイス200の少なくとも一部は、実質的に固定された時間間隔で、低アクティビティまたはアイドル状態から、より高いアクティビティ状態へ遷移することができ、次の時間間隔の満了前に低アクティビティまたはアイドル状態へ戻ることができる。一例としては、デバイス200は、実質的に固定された時間間隔で、上流デバイスと通信することができる。
【0083】
図15に示すように、一実施形態の遷移特定ロジック206は、第1の状態から第2の異なる状態へのデバイス200の少なくとも一部の遷移を特定した後の、固定された時間間隔の満了を特定して、第1の状態から第2の状態へのデバイス200の少なくとも一部の別の遷移を特定するためにタイマ1502を含んでよい。別の実施形態では、デバイス制御ロジック202は、第1の状態から第2の状態へのデバイス200の少なくとも一部の遷移を制御するためにタイマを含んでよく、一実施形態の遷移特定ロジック206は、このようなデバイス200の少なくとも一部の遷移を任意の適切な方法で特定することができる。
【0084】
図16は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図1600を示す。図16に示すように、デバイス200の少なくとも一部が、ブロック1602の第1の状態にあってよい。ブロック1604で、サービス待ち時間報告ロジック208は、第1の状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1606で、デバイス200の少なくとも一部が、第2の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1608で、サービス待ち時間報告ロジック208は、第2の状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1610で、デバイス200の少なくとも一部が、第1の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1612で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1614で、デバイス200の少なくとも一部が、第2の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。一実施形態では、このような特定は、前の第1の状態から第2の状態への遷移の特定の後の、固定された時間間隔の満了に少なくとも部分的に基づいてなされてよい。1614で特定結果が肯定的である場合、ブロック1608で、サービス待ち時間報告ロジック208は、第2のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック1608から1614の動作を繰り返してよい。
【0085】
図17は、一実施形態において、上流デバイスへサービス待ち時間を報告するデバイス200の例示的な図を示す。図17のデバイス200は、実質的に固定された時間間隔でアイドル状態からより高いアクティビティ状態へ遷移してよく、次の時間間隔の満了前にアイドル状態へ戻ることができる。図17のデバイス200は、例えば、VOIP(voice over internet protocol)デバイスであってよい。
【0086】
図17に示すように、1702でデバイス200は、より高いアクティビティ状態(デバイス200と上流デバイスとの間のデータ転送が表す)からアイドル状態へ遷移して、1ミリ秒(ms)のサービス待ち時間に対応するデータを上流デバイスに送信してよい。1704でデバイス200は、デバイス200が再度より高いアクティビティ状態に入ろうとしている場合20マイクロ秒(μs)のサービス待ち時間に対応するデータを上流デバイスへ送信してよい。デバイス200が略20msの時間間隔で、より高いアクティビティ状態に入るとき、デバイス200は、略20msの時間間隔で20マイクロ秒(μs)のサービス待ち時間に対応するデータを上流デバイスへ送信してよい。
【0087】
前述の記載では例示的な実施形態を示した。これら実施形態には様々な変形例および変更例が、添付請求項の範囲を逸脱しない範囲で可能である。故に、記載および図面は、例示的な意味合いで捉えられるべきであり、限定的に捉えられるべきものではない。
【技術分野】
【0001】
開示する実施形態は、概して電力管理に係る。
【背景技術】
【0002】
多くのデバイスおよびシステムで、電力効率を向上させるために電力管理が行われており、消費電力および/または放熱量の低減の一助となっている。電池式のモバイルデバイスおよびシステムでは、電力管理により拡張動作が可能となる。
【0003】
プラットフォームレベルの電力管理は、プラットフォームで収集された発見およびオペレーティングシステムからのガイダンスに基づいてきた。プロセッサ利用率は、プラットフォームアクティビティの概算として利用することができる。しかしながら、入出力(I/O)アクティビティが重く、プロセッサ利用率が軽い場合には、プラットフォームは低電力状態となり、I/O性能に影響が出る。実際のところ、プラットフォームが深い電力状態に入ると、直接メモリアクセス(DMA)アクセスおよび中断等のイベントを起こす際の応答待ち時間が増加する。多くのI/Oデバイスは、プラットフォームからの幾らかの固定最小応答待ち時間を許容するように設計されてはいるものの、これによって、プラットフォームが入ることのできる電力状態の深さには効果的に制限が加わりうる。プラットフォームが、その応答待ち時間がI/Oデバイスが許容可能な固定最小値よりも増加した深い電力状態に入ると、プラットフォームの機能および/または性能は危険に曝される。
【図面の簡単な説明】
【0004】
実施形態を例示として示し、添付図面による限定は意図されないが、添付図面において、同様の参照符号は同様の部材を示す。
【0005】
【図1】一実施形態において、1以上の下流デバイスからのサービス待ち時間報告に少なくとも部分的に基づいて電力管理を行う例示的なシステムのブロック図を示す。
【0006】
【図2】一実施形態において、上流デバイスへサービス待ち時間を報告する下流デバイスの例示的なブロック図を示す。
【0007】
【図3】一実施形態において、下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0008】
【図4】一実施形態において、第1の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0009】
【図5】一実施形態において、第1の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0010】
【図6】一実施形態において、第2の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0011】
【図7】一実施形態において、第2の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0012】
【図8】一実施形態において、第2の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。
【0013】
【図9】一実施形態において、第3の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0014】
【図10】一実施形態において、第3の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0015】
【図11】一実施形態において、第3の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。
【0016】
【図12】一実施形態において、第4の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0017】
【図13】一実施形態において、第5の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0018】
【図14】一実施形態において、第5の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0019】
【図15】一実施形態において、第6の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。
【0020】
【図16】一実施形態において、第6の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。
【0021】
【図17】一実施形態において、第6の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスの例示的な図を示す。
【0022】
図面は、必ずしも実寸に即して描かれていない場合がある。
【発明を実施するための形態】
【0023】
以下の詳細な記載は、電力管理のための下流デバイスのサービス待ち時間報告に関する装置、方法、およびシステムの例示的な実施形態に関する。例えば構造、機能、および/または特性等の特徴は、便宜上、一実施形態に関して示されているが、記載された特徴のうち適切な1以上のものを利用して様々な実施形態を実装することができる。
【0024】
図1は、1以上のプロセッサ110と、プロセッサ110に連結されたプラットフォーム制御ロジック120とを含む例示的なシステム100を示す。一実施形態のプロセッサ110は、1以上のプロセッサ電力管理コントローラ(PPMC)112を含み、プロセッサ110の電力効率を高めることができる。一実施形態のプラットフォーム制御ロジック120は、プラットフォームコントローラ電力管理コントローラ(PCPMC)122を含み、システム100の電力効率を高めることができる。例えば一実施形態のPCPMC122は、システム100の1以上のコンポーネントを、コンポーネントがあまりアクティブではないとき、またはアイドルのとき、複数の低電力状態またはスリープ状態のうち1つに移行させるよう管理する。
【0025】
一実施形態のPCPMC122は、システム100のコンポーネントの電力管理を調整して、電力効率を高めることができる。一実施形態のPCPMC122は、例えば、1位以上のPPMC112の間の調整を行い、これらPPMC112およびPCPMC122に、1以上のコンポーネントに関して、機能および/または性能の低下に対する懸念なく他の1以上のコンポーネントに対して応答する能力を維持できるような低電力状態の深さをより適切に特定することができる。
【0026】
一実施形態のPCPMC122は、例えばデバイス132等の1以上の下流デバイスから、そのデバイスのサービス待ち時間に対応するデータを受信してよい。一実施形態のPCPMC122は、受信データに少なくとも部分的に基づいて(故に、対応するサービス待ち時間に少なくとも部分的に基づいて)電力管理を行うことができる。一実施形態のサービス待ち時間は、そのデバイスのサービス待ち時間の許容範囲であってもよい。一実施形態のサービス待ち時間は、そのデバイスがデバイスの機能または性能に悪影響を与えずに許容できる最大待ち時間に少なくとも部分的に基づいていてよい。一実施形態のサービス待ち時間は、デバイスの少なくとも一部のアクティビティに関するレベルに対応していてよい。従って一実施形態のPCPMC122は、経時的に、デバイスの少なくとも一部のアクティビティレベルに少なくとも部分的に基づいて、デバイスから異なるサービス待ち時間を受信してよい。一実施形態のPCPMC122は、システム100の1以上のコンポーネントに関して、機能および/または性能の低下に対する懸念なくデバイスに対して応答する能力を維持できるような低電力状態の深さをより適切に特定することができる。
【0027】
一実施形態の1以上のPPMC112は、PCPMC122との間で調整を行い、下流デバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を行ってよい。一実施形態のPCPMC122は、デバイスのサービス待ち時間に対応して受信したデータを、1以上のPPMC112に送り、これらPPMC112に、このサービス待ち時間に少なくとも部分的に基づいて電力管理を行わせてよい。一実施形態の1以上のPPMC112は、このサービス待ち時間に少なくとも部分的に基づいてPCPMC122がどのように電力管理を行うか、に少なくとも部分的に基づくデバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。
【0028】
一実施形態のプラットフォーム制御ロジック120は、例えばデバイス132および134等の1以上のデバイスと通信する1以上のインタフェースコントローラ124を含むことができる。このインタフェースコントローラ124は、任意の適切な方法で1以上のデバイスとインタフェースする任意の適切なロジックを含んでよい。一実施形態の1以上のインタフェースコントローラ124は、例えば任意のユニバーサルシリアルバス(USB)仕様(例えば、USB仕様改訂版2.0、2000年4月27日、USB2.0リンク電力管理補足エンジニアリング変更報告、2007年7月16日、USB3.0仕様改訂版1.0、2008年11月12日)および/または任意の適切なPCI(Peripheral Component Interface)またはPCIエクスプレス(PCIe)仕様(例えば、PCIエクスプレスベース仕様改訂版1.0、2002年7月22日、PCIエクスプレスベース仕様改訂版2.0、2007年1月15日)等であるがこれらに限定されない任意の適切な1以上の標準的な仕様と互換性を有してよい。
【0029】
一実施形態の1以上のインタフェースコントローラ124は、1以上の下流デバイスから、そのデバイスのサービス待ち時間に対応するデータを受信して、このデータをPCPMC122に送信してよい。一実施形態の1以上のインタフェースコントローラ124は、インタフェースコントローラ電力管理コントローラ(ICPMC)126を含み、インタフェースコントローラ124および/または1以上のデバイスへの接続またはリンクのための電力効率を上げることができる。一実施形態の1以上のICPMC126は、1以上のデバイスから、そのデバイスのサービス待ち時間に対応するデータを受信して、この受信データに少なくとも部分的に基づいて、故にこれに対応するサービス待ち時間に少なくとも部分的に基づいて、電力を管理してよい。一実施形態のPCPMC122は、このサービス待ち時間に少なくとも部分的に基づいてICPMC126がどのように電力管理を行うか、に少なくとも部分的に基づくデバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。
【0030】
一実施形態のインタフェースコントローラ124は、例えばデバイス134等の別のデバイスの下流の例えばデバイス136等のデバイスのサービス待ち時間に対応するデータを受信してよい。一実施形態のデバイス134は、デバイス136から、デバイス136のサービス待ち時間に対応するデータを受信して、このデータをインタフェースコントローラ124へ送信してよい。一実施形態のデバイス134は、デバイス136から、デバイス136のサービス待ち時間に対応するデータを受信して、この受信データに少なくとも部分的に基づいて、故にこれに対応するサービス待ち時間に少なくとも部分的に基づいて、デバイス134の電力を管理してよい。一実施形態の対応するICPMC126は、このサービス待ち時間に少なくとも部分的に基づいてデバイス134がどのように電力管理を行うか、に少なくとも部分的に基づくデバイス136のサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。
【0031】
一実施形態では、システム100における電力管理は、次の文献に記載されるデバイスのサービス待ち時間に少なくとも部分的に基づいて行われてよいが、文献は、「LATENCY BASED PLATFORM COORDINATION」なる名称で、2007年12月31日に出願された米国特許出願第12/006,251号、「PLATFORM POWER MANAGEMENT BASED ON LATENCY GUIDANCE」なる名称で、2008年3月31日に出願された米国特許出願第12/059,992、および/または、「COORDINATED LINK POWER MANAGEMENT」なる名称で、2008年6月26日に出願された米国特許出願第12/146,873号である。
【0032】
図1に示すように、一実施形態のシステム100は、さらに、1以上の入力デバイス140、1以上のディスプレイ150、揮発性メモリ160、1以上の不揮発性メモリおよび/または記憶デバイス170、および1以上の通信インタフェース180を有してよい。
【0033】
一実施形態のプロセッサ110は、揮発性メモリ160にインタフェースを提供する1以上のメモリコントローラを含んでよい。揮発性メモリ160は、例えばシステム100にデータおよび/または命令をロードおよび格納するのに利用されてよい。揮発性メモリ160は、適切なダイナミックRAM(DRAM)等の任意の適切な揮発性メモリを含んでよい。一実施形態のプロセッサ110は、PPMC112を利用して揮発性メモリ160の電力管理を助けてよい。
【0034】
プロセッサ110に常駐するとして記載されているが、一実施形態の1以上のメモリコントローラは、プラットフォーム制御ロジック120に常駐することで、プラットフォーム制御ロジック120に、揮発性メモリ160と直接通信させてもよい。
【0035】
一実施形態のプラットフォーム制御ロジック120は、インタフェースコントローラ124を含む任意の適切なインタフェースコントローラを含むことで、プロセッサ110に、および/または、プラットフォーム制御ロジック120と通信する任意の適切なデバイスまたはコンポーネントに、任意の適切な通信リンクを提供してよい。一実施形態のプラットフォーム制御ロジック120は、PCPMC122を利用することで、プラットフォーム制御ロジック120と通信する任意の適切な1以上のデバイスおよび/またはコンポーネントの電力管理を助けてよい。
【0036】
一実施形態のプラットフォーム制御ロジック120は、ディスプレイ150にインタフェースを提供する1以上のグラフィックコントローラを含んでよい。例えば、ディスプレイ150は、陰極線管(CRT)または液晶ディスプレイ(LCD)等の任意の適切なディスプレイを含みうる。一実施形態の1以上のグラフィックコントローラは、プラットフォーム制御ロジック120の外にあってもよい。
【0037】
一実施形態のプラットフォーム制御ロジック120は、1以上の入出力(I/O)コントローラを含むことで、入力デバイス140、不揮発性メモリおよび/または記憶デバイス170、および通信インタフェース180へインタフェースを提供してよい。
【0038】
入力デバイス140は、キーボード、マウス、および/または任意の他の適切なカーソル制御デバイス等の任意の適切な入力デバイスを含みうる。
【0039】
不揮発性メモリおよび/または記憶デバイス170は、例えばデータおよび/または命令を記憶するのに利用されてよい。不揮発性メモリおよび/または記憶デバイス170は、例えばフラッシュメモリ等の任意の適切な不揮発性メモリを含んでよく、および/または、例えば1以上のハードディスクドライブ(HDD)、1以上のコンパクトディスク(CD)ドライブ、および/または、1以上のDVD(デジタル多用途ディスク)ドライブ等の任意の適切な不揮発性記憶デバイスを含んでよい。
【0040】
通信インタフェース180は、1以上のネットワーク上で、および/または、任意の他の適切なデバイスと通信するインタフェースをシステム100に提供してよい。通信インタフェース180は、任意の適切なハードウェアおよび/またはファームウェアを含んでよい。一実施形態の通信インタフェース180は、例えば、ネットワークアダプタ、無線ネットワークアダプタ、電話モデム、および/または、無線モデムを含んでよい。無線通信のために、一実施形態の通信インタフェース180は、1以上のアンテナ182を利用してよい。
【0041】
一実施形態の下流デバイス132、134、および136は、プラットフォーム制御ロジック120に連結されてよい任意の適切なデバイスであってよい(例えば適切な入力デバイス140、適切な不揮発性メモリまたは記憶デバイス170、適切な通信インタフェース180、または任意の他の適切なI/Oデバイス等を含むがこれらに限定されない)。下流デバイスの例には、カーソル制御デバイス、記憶ドライブ、記憶デバイス、ハブデバイス、ネットワークルータまたはスイッチ、充電デバイス、プリンタ、スキャナ、カムコーダ、カメラ、メディアプレーヤ、セルラー式電話機、スマートフォン、モバイルインターネットデバイス、およびデスクトップ、ノートブック、ネットブック等のコンピュータシステム、またはその他のコンピュータシステムが含まれうるが、これらに限定されない。
【0042】
プラットフォーム制御ロジック120に常駐するとして記載したが、1以上のインタフェースコントローラ124を含むプラットフォーム制御ロジック120の1以上のコントローラは、一実施形態では、1以上のプロセッサ110に常駐することで、プロセッサ110を、1以上のデバイスまたはコンポーネントと直接通信させることができる。1以上のインタフェースコントローラ124を含むプラットフォーム制御ロジック120の1以上のコントローラは、一実施形態では、単一のダイの上で、1以上のプロセッサ110の少なくとも一部とともに集積されてもよい。1以上のインタフェースコントローラ124を含むプラットフォーム制御ロジック120の1以上のコントローラは、一実施形態では、1以上のプロセッサ110とともにパッケージされてもよい。<サービス待ち時間の報告>
【0043】
図2は、一実施形態における、1以上の上流デバイスのサービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいて電力を管理するデバイス200を示す。一実施形態のデバイス200は、例えば図1の下流デバイス132または134に対応しており、サービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいてシステム100に電力を管理させる。一実施形態のデバイス200は、例えば図1の下流デバイス136に対応しており、サービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいてデバイス134および/またはシステム100に電力を管理させる。
【0044】
図2に示すように、一実施形態のデバイス200は、デバイス制御ロジック202、インタフェース制御ロジック204、遷移特定ロジック206、およびサービス待ち時間報告ロジック208を含んでよい。デバイス制御ロジック202、インタフェース制御ロジック204、遷移特定ロジック206、およびサービス待ち時間報告ロジック208は、それぞれ、例えば任意の適切なハードウェア、任意の適切なファームウェアを実行する任意の適切なハードウェア、任意の適切なソフトウェアを実行する任意の適切なハードウェア、または、このような実装の任意の適切な組み合わせを利用して、任意の適切な方法で実装することができる。一実施形態では、上述した任意のファームウェアおよび/またはソフトウェアが、デバイス200の任意の適切なコンピュータ可読記憶媒体(1または複数)に記憶されてよい。一実施形態のデバイス200は、さらに、デバイス200の任意の適切な機能を実装する他の適切なロジック、回路、および/または、1以上のコンポーネントを有してよい。
【0045】
一実施形態のデバイス制御ロジック202は、デバイス200の機能の制御を助けてよく、インタフェース制御ロジック204を利用して1以上の上流デバイスを通信してこれらデバイスの1以上のコンポーネントに機能を提供してよい。
【0046】
インタフェース制御ロジック204は、デバイス制御ロジック202に連結されて、任意の適切な方法でデバイス200に対してデータを送受信してよい。一実施形態のインタフェース制御ロジック204は、例えば任意のユニバーサルシリアルバス(USB)仕様および/または任意の適切なPCI(Peripheral Component Interface)またはPCIエクスプレス(PCIe)仕様等であるがこれらに限定されない任意の適切な1以上の標準的な仕様と互換性を有してよい。
【0047】
一実施形態の遷移特定ロジック206は、デバイス200の少なくとも一部の、ある状態から別の異なる状態への遷移を任意の適切な方法で特定してよい。一実施形態でこれらの状態は、デバイス200の少なくとも一部のアクティビティに関するそれぞれ異なるレベルに対応していてよい。一実施形態の遷移特定ロジック206は、デバイス制御ロジック202の少なくとも一部の、ある状態から別の異なる状態への遷移を任意の適切な方法で特定してよい。一実施形態の遷移特定ロジック206は、デバイス200の少なくとも一部が、ある状態から別の異なる状態へ遷移しようとしていることを特定することができる。一実施形態の遷移特定ロジック206は、デバイス200の少なくとも一部が、既にある状態から別の異なる状態へ遷移したことを特定することができる。
【0048】
一実施形態のサービス待ち時間報告ロジック208は、遷移特定ロジック206による遷移の特定に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック208は、任意の適切な方法で遷移特定ロジック206から状態遷移の特定を受信するよう連結されてよい。一実施形態のサービス待ち時間報告ロジック208は、インタフェース制御ロジック204を用いて任意の適切な方法でサービス待ち時間に対応するデータを送信するよう連結されてよい。
【0049】
一実施形態のサービス待ち時間報告ロジック208は、任意の適切な方法でサービス待ち時間を特定してよい。一実施形態のサービス待ち時間は、デバイス200のサービス待ち時間の許容範囲であってもよい。一実施形態のサービス待ち時間は、デバイス200がデバイス200の機能または性能に悪影響を与えずに許容できる最大待ち時間に少なくとも部分的に基づいていてよい。一実施形態のサービス待ち時間は、デバイス200の少なくとも一部の新たな状態に対応していてもよい。
【0050】
一実施形態のサービス待ち時間報告ロジック208は、前のまたは現在のサービス待ち時間および状態遷移の特定に少なくとも部分的に基づいて、新たなサービス待ち時間を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、新たな状態に少なくとも部分的に基づいて新たなサービス待ち時間を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、前のまたは現在の状態に少なくとも部分的に基づいて新たな状態を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、任意の適切な方法で遷移特定ロジック206から新たな状態の特定を受信してよい。
【0051】
デバイス200の少なくとも一部が状態間の遷移を続ける間、一実施形態のサービス待ち時間報告ロジック208は、新たなサービス待ち時間の特定をし続け、これらサービス待ち時間に対応するデータの送信を続けてよい。一実施形態のサービス待ち時間報告ロジック208は、オプションとして、新たなサービス待ち時間に対応するデータを送信しなくてもよい(例えば、新たなサービス待ち時間が、前のまたは現在のサービス待ち時間と同じである場合等)。一実施形態のサービス待ち時間報告ロジック208は、状態間の1以上であるが全てではなくてよい遷移に呼応して、新たなサービス待ち時間に対応するデータを送信してよい。
【0052】
図3は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図300を示す。図3に示すように、デバイス200の少なくとも一部が、ブロック302の第1の状態にあってよい。ブロック304で、サービス待ち時間報告ロジック208は、第1の状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック306で、デバイス200の少なくとも一部が、第2の異なる状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック308で、サービス待ち時間報告ロジック208は、第2の状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック310で、デバイス200の少なくとも一部が、第1の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック304で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック304から310の動作を繰り返してよい。
【0053】
第1および第2の状態に対応する第1および第2のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、2を越える数の状態に対応するサービス待ち時間のデータを送信することもできる。<アクティビティレベルに少なくとも部分的に基づくサービス待ち時間>
【0054】
一実施形態の遷移特定ロジック206は、互いに異なるアクティビティレベルに対応する状態間の、デバイス200の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、より高いアクティビティレベルに対応する状態に遷移するより低いサービス待ち時間に対応するデータを送信してよく、より低いアクティビティレベルに対応する状態に遷移するより高いサービス待ち時間に対応するデータを送信してよい。一実施形態の遷移特定ロジック206は、デバイス200が上流デバイスとの間でデータ通信するアクティブ状態と、デバイス200が上流デバイスとの間でデータ通信しないアイドル状態との間の、デバイス200の少なくとも一部の遷移を特定することができる。
【0055】
一実施形態のデバイス200の少なくとも一部は、たまに頻繁に、異なる状態間を遷移することができる。一例としては、一実施形態のデバイス200の少なくとも一部が、アクティビティバーストを有しているがために、たまに頻繁に、低アクティビティまたはアイドル状態に入退出することができる。一実施形態のサービス待ち時間報告ロジック208は、状態遷移が特定されてから、サービス待ち時間に対応するデータを送信するまで所定の期間を待つことにより、デバイス200の少なくとも一部が新たな状態に留まる可能性が高いか否かを特定する助けをしてよい。このようにして、一実施形態のサービス待ち時間報告ロジック208は、さもなくば1以上の上流デバイスの電力管理の効果を低減させうる、異なるサービス待ち時間に対応するデータの頻繁な送信を避けることができる。
【0056】
一実施形態のサービス待ち時間報告ロジック208は、現在のサービス待ち時間よりも高いサービス待ち時間に対応する状態への遷移が特定されてから、現在のサービス待ち時間より低いサービス待ち時間に対応する状態への遷移が特定されるまでの所定の期間を待ってよい。一例としては、一実施形態のサービス待ち時間報告ロジック208は、低アクティビティまたはアイドル状態への遷移が特定されてから、より高いアクティビティ状態への遷移が特定されるまでの所定の期間を待ってよい。
【0057】
図4に示すように、一実施形態のサービス待ち時間報告ロジック208は、新たな状態遷移の特定の後の待ち時間を特定するためにタイマ402を有してよい。一実施形態のサービス待ち時間報告ロジック208は、この待ち時間を所定の閾値と比較して、待ち時間が所定の閾値以上となるまで、新たな状態遷移のサービス待ち時間に対応するデータの送信を待ってよい。遷移特定ロジック206が所定の閾値に達する前に新たな状態遷移を特定すると、一実施形態のサービス待ち時間報告ロジック208は、この、より新しい遷移用にタイマ402をリセットしてよい。一実施形態のサービス待ち時間報告ロジック208は、この代わりに、例えばより新しい遷移の状態に少なくとも部分的に基づいて、タイマ402をリセットして、より新しい遷移のサービス待ち時間に対応するデータを送信してよい。
【0058】
図5は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図500を示す。図5に示すように、デバイス200の少なくとも一部が、ブロック502の低アクティビティまたはアイドル状態にあってよい。ブロック504で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック506で、デバイス200の少なくとも一部が、より高いアクティビティ状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック508で、サービス待ち時間報告ロジック208は、第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック510で、デバイス200の少なくとも一部が低アクティビティまたはアイドル状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック512で、サービス待ち時間報告ロジック208は、所定の期間待ってよい。ブロック514でデバイス200の少なくとも一部がまだ低アクティビティまたはアイドル状態である場合、ブロック504で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック504から514の動作を繰り返してよい。
【0059】
低アクティビティ/アイドルおよびアクティブ状態に対応するアイドルおよびアクティブのサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、例えば互いに異なるアクティビティレベルに対応する1以上の状態等の1以上のさらなる状態に対応するサービス待ち時間のデータを送信することもできる。<デバイスバッファリングに少なくとも部分的に基づくサービス待ち時間>
【0060】
一実施形態のデバイス200は、上流デバイスへの送信用に別のデバイスからデータを受信してよい。図6に示すように、一実施形態のデバイス制御ロジック202は、任意の適切な通信リンク(任意の適切な無線リンクを含む)を介して別のデバイスからデータを受信するバッファ602を含むことで、インタフェース制御ロジック204を利用してバッファ602から上流デバイスへデータを後で送信することができる。一実施形態のデバイス200は、例えば、イーサネット(登録商標)ネットワークインタフェースコントローラ(NIC)であってよい。
【0061】
デバイス200の少なくとも一部が低アクティビティまたはアイドル状態である一実施形態では、デバイス200は、デバイス200がデータを受信するためのバッファ602の利用可能な容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信する。このようにして、一実施形態の上流デバイスは、サービス待ち時間の間も対応可能である状態を維持して、バッファ602の利用可能な容量が満杯になる前にバッファ602からのデータ受信を開始することができる。サービス待ち時間がこれより高い場合には、上流デバイスは、より深く、より低い電力状態に入ることも考えられ、時を得た応答ができない可能性があり、これによりバッファ602はオーバフローして、性能が低下して、失われたデータを再送信しなければなくなる虞もある。
【0062】
一実施形態の遷移特定ロジック206は、バッファ602にデータを受信して、バッファ602からデータを再送信すべく、低アクティビティまたはアイドル状態からアクティブ状態への遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、その後、より低いサービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック208は、デバイス200がデータを受信するためのバッファ602のリザーブ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。このようにして、デバイス200は、データがバッファ602から上流デバイスへ送信され始めると、バッファ602へのデータの受信を続けることができる。
【0063】
図7は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図700を示す。図7に示すように、デバイス200の少なくとも一部が、ブロック702の低アクティビティまたはアイドル状態にあってよい。ブロック704で、サービス待ち時間報告ロジック208は、利用可能なバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック706で、デバイス200の少なくとも一部が、別のデバイスからのデータを受信または再送信するアクティブ状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック708で、サービス待ち時間報告ロジック208は、リザーブバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック710で、デバイス200の少なくとも一部が、低アクティビティまたはアイドル状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック704で、サービス待ち時間報告ロジック208は、利用可能なバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208は、オプションとして、ブロック710の状態遷移の特定の後、ブロック704のデータ送信まで、所定の期間待つことができる。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック704から710の動作を繰り返してよい。
【0064】
一実施形態のサービス待ち時間報告ロジック208は、上流デバイスがデータを受信する際のデータレートおよび/または性能要件を説明して、ブロック704および708でサービス待ち時間を特定することができる。
【0065】
低アクティビティ/アイドルおよびアクティブ状態に対応するサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、1以上のさらなる状態に対応するサービス待ち時間のデータを送信してよい。一実施形態では、サービス待ち時間報告ロジック208は、デバイス200が別のデバイスからデータを受信しうる異なる範囲のデータレートに対応する状態に対応するサービス待ち時間のデータを送信することができる。一実施形態では、サービス待ち時間報告ロジック208は、上流デバイスがデータを受信する際の異なる性能要件に対応する様々な状態に対応するサービス待ち時間のデータを送信することができる。
【0066】
図8は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。図8に示すように、バッファ602は802でネットワークデータを受信する。ネットワークデータ受信の前に、デバイス200はアイドル状態にあり、バッファ602の利用可能な容量およびネットワークデータがバッファ602に受信されるレートに少なくとも部分的に基づいて500マイクロ秒(μs)のLTR(latency tolerance report)に対応するデータを上流プラットフォームコンポーネントに送信している。デバイス200が初めにネットワークデータを受信する際、デバイス200は、アクティブ状態に遷移する、あるいは、遷移しようとしているところであり、802で、100μsのLTRに対応するデータを上流プラットフォームコンポーネントに送信する。100μsのLTRは、バッファ602のリザーブ容量およびネットワークデータがバッファ602に受信されるレートに少なくとも部分的に基づく。100μsのLTRは、バッファ602がネットワークデータを受信する間である、前の500μsのLTR期間内に有効になる。
【0067】
上流プラットフォームコンポーネントは、804、806、および808で、100μsのLTR内に応答して、バッファ602からデータを受信する。デバイス200が810でのネットワークデータの受信を終了すると、デバイス200はアイドル状態に遷移して、タイムアウトと示されている所定の時間の間、待ち、812で500μsのLTRに対応するデータを上流プラットフォームコンポーネントに送信する。図8に示すように、上流プラットフォームコンポーネントは、バッファ602からのデータ受信の際のLTRおよび応答に少なくとも部分的に基づいて様々な電力状態に入る。<電力状態に少なくとも部分的に基づくサービス待ち時間>
【0068】
一実施形態の遷移特定ロジック206は、互いに異なる電力レベルに対応する状態間の、デバイス200の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、より高い電力状態への遷移用に、より低いサービス待ち時間に対応するデータを送信してよく、より低い電力状態への遷移用に、より高いサービス待ち時間に対応するデータを送信してよい。
【0069】
図9に示すように、一実施形態のデバイス制御ロジック202は、デバイス電力管理コントローラ(DPMC)902を含み、デバイス200の電力効率を向上させることができる。一実施形態のDPMC902は、例えば、あまりアクティブまたはアイドルでない場合、デバイス200の少なくとも一部を、1以上のより低電力またはスリープ状態に入らせるよう管理することができる。
【0070】
図10は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図1000を示す。図10に示すように、デバイス200の少なくとも一部が、ブロック1002の低電力状態にあってよい。ブロック1004で、サービス待ち時間報告ロジック208は、低電力状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1006で、デバイス200の少なくとも一部が、より高い電力状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1008で、サービス待ち時間報告ロジック208は、より高い電力状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1010で、デバイス200の少なくとも一部が低電力状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1004で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック1004から1010の動作を繰り返してよい。
【0071】
より低い、および、より高い電力状態に対応する第1および第2のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、2を超える数の電力状態に対応するサービス待ち時間のデータを送信することもできる。
【0072】
図11は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。図11のデバイス200は、例えば、無線ローカルエリアネットワーク(WLAN)デバイスであってよい。図11に示すように、DPMC902は、デバイス200のラジオの電力管理を行い、1102で、低電力またはスリープ状態に入ってよい。一実施形態による図11のデバイス200は、電力管理特徴をサポートする無線プロトコルを利用して、デバイス200に、アクセスポイントまたは基地局に対して、例えばデバイス200が低電力状態に入ろうとしていることを示してよい。このようにすることで、低電力状態にある際にはデバイス200にはデータが送信されない。
【0073】
低電力状態に入る前に、デバイス200は、より高い電力状態にあり、1104で100マイクロ秒(μs)の待ち時間に対応するデータを上流デバイスに送信している。デバイス200が低電力状態に遷移する場合、デバイス200は、1106で1ミリ秒(ms)の待ち時間に対応するデータを上流デバイスに送信する。デバイス200がデータを移動してより高い電力状態に遷移する準備が整っている場合、デバイス200は1108で100μsの待ち時間に対応するデータを上流デバイスに送信する。<タスク実行に少なくとも部分的に基づくサービス待ち時間>
【0074】
一実施形態の遷移特定ロジック206は、互いに異なるタスク実行レベルに対応する状態間の、デバイス200の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック208は、より高いタスク実行状態への遷移用に、より低いサービス待ち時間に対応するデータを送信してよく、より低いタスク実行状態への遷移用に、より高いサービス待ち時間に対応するデータを送信してよい。一実施形態では、より高いタスク実行状態とは、例えば、1以上の係属中のタスクを有する状態に対応していてよい。一実施形態では、より低いタスク実行状態とは、例えば、係属中のタスクがない状態または1以上のタスクが完了した状態に対応していてよい。
【0075】
一実施形態のデバイス制御ロジック202は、デバイス200用に1以上のタスクを実行することができる。一実施形態のデバイス制御ロジック202は、自身で1以上のタスクの実行を開始することもできる。一実施形態のデバイス制御ロジック202は、別のデバイスの要求を受けて1以上のタスクを実行することもできる。一実施形態のデバイス制御ロジック202は、上流デバイスの要求を受けて1以上のタスクを実行することもできる。
【0076】
図12は、一実施形態において、デバイス200が上流デバイスにサービス待ち時間を報告する際の例示的なフロー図1200を示す。図12に示すように、デバイス200の少なくとも一部が、ブロック1202のより低いタスク実行状態にあってよい。ブロック1204で、サービス待ち時間報告ロジック208は、より低いタスク実行状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1206で、デバイス200の少なくとも一部が、より高いタスク実行状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1208で、サービス待ち時間報告ロジック208は、より高いタスク実行状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1210で、デバイス200の少なくとも一部が、より低いタスク実行状態に既に遷移したか、あるいは遷移しようとしているか、特定してよい。特定結果が肯定的である場合、ブロック1204で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック1204から1210の動作を繰り返してよい。
【0077】
より低い、および、より高いタスク実行状態に対応する第1および第2のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック208は、それぞれ異なるタスク実行レベルに対応する2を越える数の状態に対応するサービス待ち時間のデータを送信することもできる。<外部的に制御されるサービス待ち時間>
【0078】
一実施形態のサービス待ち時間報告ロジック208は、上流デバイスが特定したサービス待ち時間に対応するデータを上流デバイスに送信してよい。一実施形態のデバイス200は、例えばデバイス200が厳しくないサービス待ち時間を有していたり、あまり頻繁に変化しないサービス待ち時間を有したりしている場合等に、上流デバイスが特定しうるサービス待ち時間を有してよい。一実施形態のデバイス200は、例えばデバイス200が、上流デバイスが予定する1以上のタスクを行う場合等に、上流デバイスが特定しうるサービス待ち時間を有してよい。一実施形態の上流デバイスは、タスクを予定する前にデバイス200についてより低いサービス待ち時間を特定してよく、全ての予定されていたタスクが完了すると、デバイス200についてより高いサービス待ち時間を特定してよい。
【0079】
一実施形態の上流デバイスは、上流デバイスが特定するサービス待ち時間に対応するデータをデバイス200へ送信してよい。一実施形態の上流デバイスは、デバイス200のサービス待ち時間を特定すべくソフトウェアを実行してよい。一実施形態ではこのようなソフトウェアは、例えば、デバイス200のドライバソフトウェアであってよい。
【0080】
図13に示すように、一実施形態のサービス待ち時間報告ロジック208は、サービス待ち時間に対応するデータを上流デバイスから受信するためのメモリ1302を含んでよい。一実施形態では、メモリ1302の少なくとも一部が、上流デバイスのメモリ空間にマッピングされてよい。一実施形態のメモリ1302は、1以上のレジスタを含んでよい。一実施形態のメモリ1302は、メモリマッピングされた入出力(MMIO)レジスタであってよい。
【0081】
図14は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図1400を示す。図14に示すように、ブロック1402でサービス待ち時間報告ロジック208は、上流デバイスが特定したサービス待ち時間に対応するデータを上流デバイスから受信してよい。一実施形態の上流デバイスは、このデータをソフトウェア実行の際に送信してよい。ブロック1404でサービス待ち時間報告ロジック208は、ブロック1402で受信したデータに少なくとも部分的に基づいてサービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック208は、ブロック1404で、上流デバイスの電力管理コントローラへデータを送信してよい。<定期的な遷移に少なくとも部分的に基づくサービス待ち時間>
【0082】
一実施形態のデバイス200の少なくとも一部は、実質的に固定された時間間隔で、第1の状態から第2の異なる状態へと遷移することができる。一実施形態のデバイス200の少なくとも一部は、実質的に固定された時間間隔で、低アクティビティまたはアイドル状態から、より高いアクティビティ状態へ遷移することができ、次の時間間隔の満了前に低アクティビティまたはアイドル状態へ戻ることができる。一例としては、デバイス200は、実質的に固定された時間間隔で、上流デバイスと通信することができる。
【0083】
図15に示すように、一実施形態の遷移特定ロジック206は、第1の状態から第2の異なる状態へのデバイス200の少なくとも一部の遷移を特定した後の、固定された時間間隔の満了を特定して、第1の状態から第2の状態へのデバイス200の少なくとも一部の別の遷移を特定するためにタイマ1502を含んでよい。別の実施形態では、デバイス制御ロジック202は、第1の状態から第2の状態へのデバイス200の少なくとも一部の遷移を制御するためにタイマを含んでよく、一実施形態の遷移特定ロジック206は、このようなデバイス200の少なくとも一部の遷移を任意の適切な方法で特定することができる。
【0084】
図16は、一実施形態において、デバイス200が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図1600を示す。図16に示すように、デバイス200の少なくとも一部が、ブロック1602の第1の状態にあってよい。ブロック1604で、サービス待ち時間報告ロジック208は、第1の状態に対応する第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1606で、デバイス200の少なくとも一部が、第2の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1608で、サービス待ち時間報告ロジック208は、第2の状態に対応する第2のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1610で、デバイス200の少なくとも一部が、第1の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック1612で、サービス待ち時間報告ロジック208は、第1のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック206は、ブロック1614で、デバイス200の少なくとも一部が、第2の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。一実施形態では、このような特定は、前の第1の状態から第2の状態への遷移の特定の後の、固定された時間間隔の満了に少なくとも部分的に基づいてなされてよい。1614で特定結果が肯定的である場合、ブロック1608で、サービス待ち時間報告ロジック208は、第2のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック208および遷移特定ロジック206は、このようにしてブロック1608から1614の動作を繰り返してよい。
【0085】
図17は、一実施形態において、上流デバイスへサービス待ち時間を報告するデバイス200の例示的な図を示す。図17のデバイス200は、実質的に固定された時間間隔でアイドル状態からより高いアクティビティ状態へ遷移してよく、次の時間間隔の満了前にアイドル状態へ戻ることができる。図17のデバイス200は、例えば、VOIP(voice over internet protocol)デバイスであってよい。
【0086】
図17に示すように、1702でデバイス200は、より高いアクティビティ状態(デバイス200と上流デバイスとの間のデータ転送が表す)からアイドル状態へ遷移して、1ミリ秒(ms)のサービス待ち時間に対応するデータを上流デバイスに送信してよい。1704でデバイス200は、デバイス200が再度より高いアクティビティ状態に入ろうとしている場合20マイクロ秒(μs)のサービス待ち時間に対応するデータを上流デバイスへ送信してよい。デバイス200が略20msの時間間隔で、より高いアクティビティ状態に入るとき、デバイス200は、略20msの時間間隔で20マイクロ秒(μs)のサービス待ち時間に対応するデータを上流デバイスへ送信してよい。
【0087】
前述の記載では例示的な実施形態を示した。これら実施形態には様々な変形例および変更例が、添付請求項の範囲を逸脱しない範囲で可能である。故に、記載および図面は、例示的な意味合いで捉えられるべきであり、限定的に捉えられるべきものではない。
【特許請求の範囲】
【請求項1】
装置であって、
第1の状態から第2の状態への下流デバイスの少なくとも一部の遷移を特定する第1のロジックと、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせる第2のロジックとを備え、
前記第1の状態および前記第2の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している装置。
【請求項2】
前記第2のロジックは、前記遷移の特定の後に、前記データの送信まで所定の時間待つ請求項1に記載の装置。
【請求項3】
前記第2の状態はアイドル状態である請求項2に記載の装置。
【請求項4】
前記第2の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項1に記載の装置。
【請求項5】
前記第2の状態はアクティブ状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファのリザーブ容量に少なくとも部分的に基づく請求項1に記載の装置。
【請求項6】
前記第2の状態は、前記第1の状態より低い電力状態である請求項1に記載の装置。
【請求項7】
前記第1の状態は前記下流デバイスによる1以上のタスクの実行に対応しており、前記第2の状態は前記下流デバイスによる1以上のタスクの完了に対応している請求項1に記載の装置。
【請求項8】
前記第2のロジックは、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する請求項1に記載の装置。
【請求項9】
前記下流デバイスの少なくとも一部は、実質的に固定された時間間隔で前記第1の状態から前記第2の状態へ遷移する請求項1に記載の装置。
【請求項10】
前記第1のロジックは、前記下流デバイスの少なくとも一部が前記第1の状態から前記第2の状態へ遷移しようとしていることを特定する請求項1に記載の装置。
【請求項11】
前記第1のロジックは、前記下流デバイスの少なくとも一部が前記第1の状態から前記第2の状態へ遷移したことを特定する請求項1に記載の装置。
【請求項12】
方法であって、
第1の状態から、第2の状態への下流デバイスの少なくとも一部の遷移を特定する段階と、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせる段階とを備え、
前記第1の状態および前記第2の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している方法。
【請求項13】
前記遷移の特定の後に、前記データの送信まで所定の時間待つ段階を備える請求項12に記載の方法。
【請求項14】
前記第2の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項12に記載の方法。
【請求項15】
前記第2の状態は、前記第1の状態より低い電力状態である請求項12に記載の方法。
【請求項16】
前記第1の状態は前記下流デバイスによる1以上のタスクの実行に対応しており、前記第2の状態は前記下流デバイスによる1以上のタスクの完了に対応している請求項12に記載の方法。
【請求項17】
前記送信する段階は、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する段階を有する請求項12に記載の方法。
【請求項18】
実質的に固定された時間間隔で前記下流デバイスの少なくとも一部が前記第1の状態から前記第2の状態へ遷移する段階を備える請求項12に記載の方法。
【請求項19】
下流デバイスであって、
第1の状態から第2の状態への前記下流デバイスの少なくとも一部の遷移を特定する第1のロジックと、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせる第2のロジックと、
前記下流デバイスの機能の制御を助ける第3のロジックとを備え、
前記第1の状態および前記第2の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している下流デバイス。
【請求項20】
前記第2のロジックは、前記遷移の特定の後に、前記データの送信まで所定の時間待つ請求項19に記載の下流デバイス。
【請求項21】
前記第2の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項19に記載の下流デバイス。
【請求項22】
前記第2の状態は、前記第1の状態より低い電力状態である請求項19に記載の下流デバイス。
【請求項23】
前記第1の状態は前記下流デバイスによる1以上のタスクの実行に対応しており、前記第2の状態は前記下流デバイスによる1以上のタスクの完了に対応している請求項19に記載の下流デバイス。
【請求項24】
前記第2のロジックは、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する請求項19に記載の下流デバイス。
【請求項25】
前記下流デバイスの少なくとも一部は、実質的に固定された時間間隔で前記第1の状態から前記第2の状態へ遷移する請求項19に記載の下流デバイス。
【請求項1】
装置であって、
第1の状態から第2の状態への下流デバイスの少なくとも一部の遷移を特定する第1のロジックと、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせる第2のロジックとを備え、
前記第1の状態および前記第2の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している装置。
【請求項2】
前記第2のロジックは、前記遷移の特定の後に、前記データの送信まで所定の時間待つ請求項1に記載の装置。
【請求項3】
前記第2の状態はアイドル状態である請求項2に記載の装置。
【請求項4】
前記第2の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項1に記載の装置。
【請求項5】
前記第2の状態はアクティブ状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファのリザーブ容量に少なくとも部分的に基づく請求項1に記載の装置。
【請求項6】
前記第2の状態は、前記第1の状態より低い電力状態である請求項1に記載の装置。
【請求項7】
前記第1の状態は前記下流デバイスによる1以上のタスクの実行に対応しており、前記第2の状態は前記下流デバイスによる1以上のタスクの完了に対応している請求項1に記載の装置。
【請求項8】
前記第2のロジックは、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する請求項1に記載の装置。
【請求項9】
前記下流デバイスの少なくとも一部は、実質的に固定された時間間隔で前記第1の状態から前記第2の状態へ遷移する請求項1に記載の装置。
【請求項10】
前記第1のロジックは、前記下流デバイスの少なくとも一部が前記第1の状態から前記第2の状態へ遷移しようとしていることを特定する請求項1に記載の装置。
【請求項11】
前記第1のロジックは、前記下流デバイスの少なくとも一部が前記第1の状態から前記第2の状態へ遷移したことを特定する請求項1に記載の装置。
【請求項12】
方法であって、
第1の状態から、第2の状態への下流デバイスの少なくとも一部の遷移を特定する段階と、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせる段階とを備え、
前記第1の状態および前記第2の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している方法。
【請求項13】
前記遷移の特定の後に、前記データの送信まで所定の時間待つ段階を備える請求項12に記載の方法。
【請求項14】
前記第2の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項12に記載の方法。
【請求項15】
前記第2の状態は、前記第1の状態より低い電力状態である請求項12に記載の方法。
【請求項16】
前記第1の状態は前記下流デバイスによる1以上のタスクの実行に対応しており、前記第2の状態は前記下流デバイスによる1以上のタスクの完了に対応している請求項12に記載の方法。
【請求項17】
前記送信する段階は、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する段階を有する請求項12に記載の方法。
【請求項18】
実質的に固定された時間間隔で前記下流デバイスの少なくとも一部が前記第1の状態から前記第2の状態へ遷移する段階を備える請求項12に記載の方法。
【請求項19】
下流デバイスであって、
第1の状態から第2の状態への前記下流デバイスの少なくとも一部の遷移を特定する第1のロジックと、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を1以上の上流デバイスに行わせる第2のロジックと、
前記下流デバイスの機能の制御を助ける第3のロジックとを備え、
前記第1の状態および前記第2の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している下流デバイス。
【請求項20】
前記第2のロジックは、前記遷移の特定の後に、前記データの送信まで所定の時間待つ請求項19に記載の下流デバイス。
【請求項21】
前記第2の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項19に記載の下流デバイス。
【請求項22】
前記第2の状態は、前記第1の状態より低い電力状態である請求項19に記載の下流デバイス。
【請求項23】
前記第1の状態は前記下流デバイスによる1以上のタスクの実行に対応しており、前記第2の状態は前記下流デバイスによる1以上のタスクの完了に対応している請求項19に記載の下流デバイス。
【請求項24】
前記第2のロジックは、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する請求項19に記載の下流デバイス。
【請求項25】
前記下流デバイスの少なくとも一部は、実質的に固定された時間間隔で前記第1の状態から前記第2の状態へ遷移する請求項19に記載の下流デバイス。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【公開番号】特開2010−165350(P2010−165350A)
【公開日】平成22年7月29日(2010.7.29)
【国際特許分類】
【外国語出願】
【出願番号】特願2009−293551(P2009−293551)
【出願日】平成21年12月24日(2009.12.24)
【出願人】(591003943)インテル・コーポレーション (1,101)
【Fターム(参考)】
【公開日】平成22年7月29日(2010.7.29)
【国際特許分類】
【出願番号】特願2009−293551(P2009−293551)
【出願日】平成21年12月24日(2009.12.24)
【出願人】(591003943)インテル・コーポレーション (1,101)
【Fターム(参考)】
[ Back to top ]