差分
このページの2つのバージョン間の差分を表示します。
| 両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン | ||
|
freebsd:tuning_power_consumption [2019-11-29 13:09] Decomo |
freebsd:tuning_power_consumption [2019-12-01 19:16] (現在) Decomo |
||
|---|---|---|---|
| 行 1: | 行 1: | ||
| ====== FreeBSD WikiのTuningPowerConsumptionの日本語訳 ====== | ====== FreeBSD WikiのTuningPowerConsumptionの日本語訳 ====== | ||
| + | |||
| + | 家鯖の消費電力を下げるべく情報を集めていたところ、FreeBSD Wikiの[[https:// | ||
| ===== 消費電力チューニング ===== | ===== 消費電力チューニング ===== | ||
| - | Alexandar Motin 記す: | + | Alexandar Motin 記す： |
| FreeBSDでの消費電力削減に関して私の知るところをまとめ、FreeBSD 8.x/ | FreeBSDでの消費電力削減に関して私の知るところをまとめ、FreeBSD 8.x/ | ||
| 行 10: | 行 12: | ||
| - | ここから順にみていきます。 | + | ここから順にみていきます： |
| ==== 1. CPU ==== | ==== 1. CPU ==== | ||
| - | CPUはシステムで最も消費する部分です。 | + | CPUはシステム内で最も電力を消費する部分です。 |
| - | フル稼働下ではそれだけで40W以上の電力を消費しますが、実際のラップトップ利用で最も重要なのはアイドル消費電力です。 | + | 最大負荷時では、CPUだけで40W以上を消費するでしょうが、実際のラップトップ利用において最も重要なのはアイドル時消費電力です。 |
| - | Core2Duo T7700 CPUは2つのコアを持ち、2.4GHzで動作し、2400, 2000, 1600, 1200, 800MHzの段階のPステートを使うEISTテクノロジーをサポートし、C1, C2, C3の待機Cステートと加えてスロットリングをサポートします。 | + | Core2Duo T7700 CPUは2つのコアを持ち、2.4GHzで駆動し、2400/2000/1600/1200/800MHzのPステートからなるEISTテクノロジに対応し、C1/C2/C3の待機Cステートに加えスロットリングをサポートします。 |
| - | では、どうやってそれを使うのでしょうか: | + | ではどのようにそれらを使えばいいのでしょうか： |
| === Pステートとスロットリング === | === Pステートとスロットリング === | ||
| - | powerdを有効にすると、CPU負荷に応じてCPUの周波数/ | + | '' |
| - | 最近のシステムではpowerdがそれらを完全に透過的に扱うことが可能です。 | + | |
| - | デフォルトでは、周波数はEISTとスロットリングテクノロジーの絡み合いを通じて制御されます。 | + | |
| - | 前者はコア周波数と電圧の両方を制御し、後者はコア周波数のみを制御します。 | + | |
| - | 両テクノロジーは確かな省電力効果を生みます。 | + | |
| - | しかし、スロットリングの効果は小さく、またC2ステートを使うことで完全に隠れてしまいます。そんなわけで、スロットリング制御を無効化するために''/ | + | |
| - | <code conf> | + | r265329以前では、周波数はEISTとスロットリング技術を混合して制御されていました。 |
| + | 前者がコア周波数と電圧の両方を制御し、後者はコア周波数のみを制御します。 | ||
| + | 両技術は電力削減に良い影響をもたらしますが、スロットリングの効果は小さく、C2ステートを使うことで完全に隠れてしまうでしょう。 | ||
| + | そんなわけで、''/ | ||
| + | |||
| + | < | ||
| hint.p4tcc.0.disabled=1 | hint.p4tcc.0.disabled=1 | ||
| hint.acpi_throttle.0.disabled=1 | hint.acpi_throttle.0.disabled=1 | ||
| </ | </ | ||
| - | この後の'' | + | これ以後、'' |
| < | < | ||
| 行 39: | 行 42: | ||
| </ | </ | ||
| - | Intel Turbo Boost機能の制御のために、ACPIは公称クロック周波数より1MHz多い追加の性能レベルを報告するかもしれません。 | + | 新規インストールにおいて、ACPIとP4TCCスロットリングは、今やデフォルトで無効になっています。 |
| - | 例えば、Core i7-870では下記のようなレポートを見ることができるでしょう： | + | |
| + | Intel TurboBoost動作の制御のため、ACPIは公称周波数より1MHz高い追加の性能レベルを表示するかもしれません。 | ||
| + | 例えばCore i7-870では以下のように見えるでしょう： | ||
| < | < | ||
| 行 46: | 行 52: | ||
| </ | </ | ||
| - | ここで2933は2.93GHzを意味しますが、2934はシチュエーションに依存し、3.2～3.6GHzを表します。 | + | 値の2933は2.93GHzを意味しますが、2934は状況に依存し3.2～3.6GHzを意味します。 |
| + | |||
| + | 私のケースでは、周波数/ | ||
| - | 私のケースでは、周波数/ | ||
| === Cステート === | === Cステート === | ||
| - | C1は非アクティブの間、CPUコアの幾つかの部分のクロックを止めます。 | + | C1ステートはCPUが活動していない間、コアのいくつかの部分のクロックを停止します。 |
| - | これは安全で安上がりであり、長いことCPUにサポートされてきました。 | + | これは安全で、性能へのインパクトも少なく、昔からCPUでサポートされています。 |
| - | システムは標準でC1ステートを使用します。 | + | システムは標準でC1ステートを使います。 |
| - | C2は待機時に全コアクロックの停止をCPUに許可します。 | + | C2ステートは待機時にCPUの全コアクロックの停止を可能にします。 |
| - | これもまた安価ですが、使用にはACPI-チップセット-CPUの正確な協調動作が求められます。 | + | これもまた安上がりですが、利用にあたりACPI/チップセット/CPU間の正確な協調動作が求められます。 |
| - | C2ステートの使用は''/ | + | C2ステートの有効化は''/ |
| - | < | + | < |
| performance_cx_lowest=" | performance_cx_lowest=" | ||
| economy_cx_lowest=" | economy_cx_lowest=" | ||
| </ | </ | ||
| - | '' | + | '' |
| - | C3ステートは、CPUが全ての内部クロックを完全に停止し、電圧を下げ、システムバスからの切り離しを許可します。 | + | C3ステートは、CPUの完全な内部クロック停止、電圧の削減、そしてシステムバスからの切り離しを可能にします。 |
| - | このステートは更なる省エネ効果をもたらしますが、安くはなくトレードオフを必要とします。 | + | このステートは更なる省エネ効果をもたらすものの、安上がりではなく、トレードオフが求められます。 |
| - | C3ステートでCPUが完全に止まると同時に、FreeBSDがSMP環境下でイベントタイマーとして使用する各CPUコア内のローカルAPICタイマーは機能しなくなります。 | + | C3ステートでCPUが完全に止まるや否や、FreeBSDがSMP環境でイベントソースとして利用する各CPUコア内のローカルAPICタイマーは機能しなくなります。システムタイムが止まり、スケジューリングを破壊し、これはシステムを死へと誘います。 |
| - | それはシステムタイマーを止め、スケジューリングを破壊し、システムを死へと誘います。 | + | この問題に対する唯一の解決策は、いくつかの外部タイマを使う事です。 |
| - | この問題に対する唯一の解決策は幾つかの外部タイマーを使うことです。 | + | |
| - | C1Eとして知られる擬似ステートもあります。 | + | C1Eとして知られる疑似ステートもあります。 |
| - | これはCステート対応のないOSで、モダンなCPUがより上手く動くための次善策です。 | + | これは、現代的なCPUとCステート非対応のOSとがより良く動くための次善策です。 |
| - | BIOSで有効にすると、OSによってC1ステートを要求された際に、CPUが幾つかのより深いCステートに入る事を可能にします。 | + | BIOSで有効にすると、OSからC1ステートが要求された際、CPUはより深いCステートに入れるようになります。 |
| + | |||
| + | 典型的にAMD CPUとBIOSは実際のCステートをOSに見せませんが、かわりにC1Eメカニズムを用いるのみです。 | ||
| + | 例えば次のように働くでしょう：OSがいくつかのCPUコアにC1を要求するとコアはC2に入りますが、CPUパッケージの全コアがC2である時は、パッケージの全てがC3になるという具合です。 | ||
| + | あいにく、この働きはOSから完全に隠蔽されています。 | ||
| - | 通常、AMDのCPUとBIOSは実際のCステートをOSに見せませんが、代わりにC1Eメカニズムだけを使います。 | ||
| - | 例えば、それはこのように動くかもしれません：OSが幾つかのCPUコアにC1を要求した時、コアはC2に入りますが、幾つかのCPUパッケージの全コアがC2の時は、そのパッケージ全体がC3に入ります。 | ||
| - | あいにく、この動きはOSから完全に隠蔽されています。 | ||
| == FreeBSD 8.x == | == FreeBSD 8.x == | ||
| - | 当初、SMP時代の前、FreeBSDはi8254（周波数用）とRTC（ステート用）チップセットタイマーを使いました。 | + | もともと、SMP時代以前、FreeBSDはi8254（周波数用）とRTC（ステータス用）のチップセットタイマを使っていました。 |
| - | FreeBSD 8.2はそれらをSMPシステム用に蘇らせます。 | + | FreeBSD 8.xはこれらをSMPシステム用に復活させました。 |
| - | それらを使うために、''/ | + | これらを使うために、''/ |
| - | < | + | < |
| hint.apic.0.clock=0 | hint.apic.0.clock=0 | ||
| </ | </ | ||
| - | 同様に、C3における電圧昇降のために、CPUは時間を必要とします（私のシステムでは57us）。 | + | C3の電圧昇降には、もちろんCPUは時間を必要とします（私のシステムでは57マイクロ秒）。 |
| - | これはシステムがしばしば目覚める場合、C3ステートが効率的に利用されない事を意味します。 | + | これはつまり、頻繁にアクティブになるシステムにおいて、C3ステートは効率的に利用されないという事です。 |
| - | 非アクティブ期間を増加させるには、'' | + | 非アクティブ期間を増やすため、可能な限り割り込みレートを下げるべきです。'' |
| - | < | + | < |
| kern.hz=100 | kern.hz=100 | ||
| </ | </ | ||
| - | これによりシステム応答時間が僅かに増加するかもしれませんが、ラップトップにとって重要なことではありません。 | + | システムの応答時間がわずかに増えるかもしれませんが、ラップトップでは重大事ではありません。 |
| - | 別の新規オプションを追加することで、RTCの代わりに静的コレクション用途のi8254タイマを用いて、スケジューリング精度のコストによる1コア毎秒間128回の追加割込みを回避することもできるでしょう。 | + | 同様に、RTCクロックの代わりに静的コレクション用途のi8254タイマーを用いて、スケジューリング精度に必要な1コアあたり秒間128回の追加割り込みを避けるとよいかもしれません。そのためには別の新規オプションを追加します： |
| - | < | + | < |
| hint.atrtc.0.clock=0 | hint.atrtc.0.clock=0 | ||
| </ | </ | ||
| - | 結果として、システムはコア毎に100割り込みを持つだけとなり、CPUは高効率でC3を使っています： | + | 結果として、システムはコアあたり100回の割り込みで済み、CPUは効率的にC3を使っています： |
| < | < | ||
| 行 118: | 行 125: | ||
| </ | </ | ||
| - | 効果的なC3ステート使用の結果、C2+powerdと比較して約2Wの削減です。 | + | 効率的なC3使用の結果、C2+powerdと比べて約2Wの削減です。 |
| + | |||
| + | AMD CPUにおいてC1Eステートへの突入は、予期せぬ制御不能なC3ステートへ突入しているかもしれず、ローカルAPICタイマーの停止を引き起こす可能性があるため、FreeBSD 8.xはC1E機能を完全にブロックします。 | ||
| - | AMD CPUにおいてC1Eステートへの突入は、予測不能で制御不能なC3ステートへの落下を引き起こし、ひいてはローカルAPICタイマの停止に繋がる可能性があるため、FreeBSD 8.xではC1E機能を完全にブロックします。 | ||
| == FreeBSD 9.x == | == FreeBSD 9.x == | ||
| - | FreeBSD 9.xは新しいイベントタイマーサブシステム'' | + | FreeBSD 9.xは新イベントタイマーサブシステム'' |
| - | システムは最適と思われるタイマーを自動的に選択しますが、'' | + | システムは最適と思われるタイマーを自動的に選択しますが、'' |
| - | また、'' | + | また'' |
| - | これにより'' | + | これにより'' |
| - | それでもなお'' | + | それでもなお'' |
| - | FreeBSD 9.x adds check whether it safe to use specific | + | FreeBSD 9.xでは具体的なCステートと現在のイベントタイマが安全に使えるかどうかのチェックが追加され、場合によってはより安全となるようC2/C3が自動的にブロックされます。 |
| - | それでもなお、ある種の作業負荷において性能低下の原因となるため、Cステートの使用は今も標準では有効になっておらず、手動で有効にしなければなりません。 | + | そうはいっても、いくつかのワークロードにおいて性能低下の可能性があるため、Cステートの利用は現在デフォルトでは有効になっておらず、手動で有効にしなければなりません。 |
| - | と同時に新しいCPUでは、より深いCステートの有効化はTurboBoostテクノロジーの利用を可能にし、これによりシングルスレッドアプリケーション性能が増加するでしょう。 | + | それと同時に、より新しいCPUにおいて、深いCステートを有効にすることはTurboBoost技術の利用を可能とし、これはシングルスレッドアプリケーションの性能向上につながります。 |
| - | AMD CPUでは、FreeBSD 9.xはローカルAPICタイマーが使われている時に限りC1Eをブロックします。 | + | AMD CPUの場合、FreeBSD 9.xはローカルAPICタイマが使われている場合のみC1Eステートをブロックします。 |
| - | もし起動時からずっとそのローカルAPICタイマーが使われていた場合、次の再起動までC1Eはブロックされます。 | + | 起動の時点でローカルAPICタイマが使われていた場合、次回再起動までC1Eはブロックされるでしょう。 |
| - | C1E動作を許可するために、強制的にその他のタイマーを使うのがよいかもしれません。 | + | C1Eの動作を許可するには、他のタイマが使われるよう強制する必要があるかもしれません。 |
| - | ==== 2. 画面 / ビデオカード | + | ==== 2. 画面/ |
| - | 画面のバックライトは多くの電力を消費する可能性があります。 | + | 画面のバックライトは、そこそこ電気を食います。 |
| + | 私のラップトップでは、明るさによって最小1.5W～最大4Wでした。 | ||
| + | したがって、明るさを（ハード的またはソフト的に）制御する方法を見つけ、状況に応じて最小限のレベルに合わせるのが良いでしょう。 | ||
| + | 私の場合、それはハードウェアのボタンで制御されます。 | ||
| + | 他のいくつかのラップトップでは、明るさ制御を'' | ||
| + | グラフィックチップは使うドライバやその設定に応じて、著しい量の電力を消費する可能性があります。 | ||
| - | 私のラップトップでは最低輝度の1.5Wから最大輝度の4Wでした。 | ||
| - | 従って、（ハードウェアやソフトウェアで）輝度を制御する方法を見つけ、状況に応じた最低輝度レベルの調整を行うべきです。 | ||
| - | 私の場合、ハードウェアのボタンで制御しました。 | ||
| - | '' | ||
| - | グラフィックチップはかなりの量の電力を消費する可能性があり、それは使用するドライバとその設定によって決まるかもしれません。 | ||
| - | === Intel GPUs === | + | === Intel GPU === |
| - | SandyBridge/ | + | SandyBridge/ |
| - | ''/ | + | ''/ |
| <code conf> | <code conf> | ||
| 行 158: | 行 166: | ||
| </ | </ | ||
| - | GPUの電力節約待機ステートの使用を有効にし、消費電力を削減します。 | + | 電力を抑えるGPUの待機ステートの使用を有効化し、消費電力を削減します。 |
| + | |||
| + | <note warning> | ||
| + | |||
| + | 参考： | ||
| + | * [[https:// | ||
| + | * [[https:// | ||
| + | * '' | ||
| === NVIDIA Optimus === | === NVIDIA Optimus === | ||
| - | If you have a Laptop with an NVIDIA Optimus GPU where you cannot switch off either GPU off in the Laptop' | + | NVIDIA Optimus対応GPU搭載のラップトップを持っており、BIOSでGPUオフができなければ、単体NVIDIA GPUの無効化に使われる全ての基地のACPIコールを調査するお手製スクリプトがあります： |
| + | < | ||
| % fetch https:// | % fetch https:// | ||
| % make -C / | % make -C / | ||
| % vim turn_off_gpu.sh | % vim turn_off_gpu.sh | ||
| % sh turn_off_gpu.sh | % sh turn_off_gpu.sh | ||
| + | </ | ||
| - | Once successful, it will store the succeeded call in | + | 成功したACPIコールは、以下に格納されます。 |
| + | < | ||
| / | / | ||
| + | </ | ||
| + | |||
| + | そして後続の処理で使用されます。 | ||
| + | ASUSのウルトラブックにおいて、これは6～8Wを節約し、バッテリー駆動時間を少なくとも3時間延ばします。 | ||
| + | 起動時にGPUを無効化するために、'' | ||
| + | 上述のIntel GPUセクションに加えて''/ | ||
| - | and use it on subsequent tries. On an ASUS UltraBook, this saves about 6-8W and raises battery lifetime by a third at least. It can be put into rc.local or other custom rc.d scripts to disable the GPU on boot. It can be used in addition to the / | ||
| ==== 3. メモリ ==== | ==== 3. メモリ ==== | ||
| - | このラップトップは2枚の1GB DDR2-667 SODIMMメモリモジュールが取り付けられています。 | + | このラップトップは2枚の1GB DDR2-667 SODIMMメモリモジュールが組み込まれています。 |
| - | そのうちの1枚を外すと約1Wの節電、2枚の1GBモジュールを1枚の2GBモジュールに置き換えると0.5Wの節電です。 | + | そのうち1枚を取ることで約1Wの節約、2枚の1GBモジュールを1枚の2GBモジュールに置き換えることでも約0.5Wの節約です。 |
| - | ==== 4. PCIデバイス ==== | ||
| - | PCIバスはデバイス電力を制御する仕組みを提供します。 | + | ==== 4. PCIデバイス ==== |
| - | 例えば、私はFireWireコントローラは全く使用せず、殆どの時間においてEHCI USBコントローラも同様です。 | + | |
| - | それらを無効にする事で約3Wの節電が可能です。 | + | PCIバスはデバイスの電源管理手法を提供します。 |
| - | 不要な全てのPCIデバイスの無効化には、それらのドライバを抜いてカーネルをビルドしなければなりません。そして'' | + | たとえば、私は全く使わないFireWireコントローラと殆ど使うことがないEHCI USBコントローラを持っています。 |
| + | これらを無効化することで3Wの電力削減ができます。 | ||
| + | 全ての不要なPCIデバイスの無効化のために、それらのドライバを外したカーネルをビルドし、'' | ||
| <code conf> | <code conf> | ||
| 行 191: | 行 215: | ||
| </ | </ | ||
| - | デバイス再有効のためにしなければならない事は、それらのドライバをモジュールとしてただ読み込む事だけです。 | + | デバイスを再び有効化するために必要なことは、それらのドライバをモジュールとして単に読み込むだけです。 |
| - | 8.xの新しいEHCI USBドライバは以前のものより少ない電力を消費します。 | + | 8.xの新しいEHCI USBドライバは以前のものよりも消費電力が少なくなっています。 |
| - | ==== 5. 無線 ==== | ||
| - | WiFiとBluetoothのアダプタは、使用時（当方の'' | + | ==== 5. 無線 ==== |
| - | いくつかのWiFiアダプタ（当方の'' | + | WiFiとBluetoothアダプタは、使用時（私の場合'' |
| - | これを有効にするには、以下のオプションを'' | + | |
| - | < | + | ある種のWiFiアダプタ（私の'' |
| + | これは | ||
| + | < | ||
| powersave | powersave | ||
| </ | </ | ||
| + | オプションを'' | ||
| + | わずかな接続レイテンシの増加と引き換えに、大幅なWiFi消費電力を削減するでしょう。 | ||
| - | この有意義なWiFi消費電力の削減は、リンク遅延の若干の増加と引き換えに行われる可能性があります。 | ||
| - | ==== 6. HDAモデム ==== | + | ==== 6. HDAモデム ==== |
| - | 私は驚いたのですが、内蔵HDAモデムは未使用時でさえ約1Wの電力を消費していました。 | + | 私は驚いたのですが、内蔵HDAモデムは使用していなくとも約1Wの電力を消費していました。 |
| - | 私は最も過激な解決策を用いました─物理的にソケットから外したのです。 | + | 私は最も過激な解決策、すなわちソケットから物理的に取り外す選択をしました。 |
| - | その場所にあたるケースの表面の温度が以前より下がりました。 | + | モデムがあった場所のケース表面温度は下がりました。 |
| - | ==== 7. HDAサウンド ==== | + | ==== 7. HDAサウンド ==== |
| - | サウンド生成割り込みの数を減らすため、私は'' | + | サウンドが生成する割り込み数を減らすため、'' |
| <code conf> | <code conf> | ||
| 行 221: | 行 246: | ||
| </ | </ | ||
| - | 2012-03-10以前のFreeBSD 9-STABLEでは、最大バッファサイズを増やす事も有益かもしれません： | + | 2012-03-10のFreeBSD 9-STABLE以前では、最大バッファサイズを増やすことも有益かもしれません： |
| <code conf> | <code conf> | ||
| 行 228: | 行 253: | ||
| </ | </ | ||
| - | ==== 8. HDD ==== | + | ==== 8. HDD ==== |
| - | First common recommendation is use tmpfs for temporary files. | + | まず、よくある推奨方法は一時ファイル用に'' |
| + | RAMは消費電力への影響が少なく、速くanyway with you。 | ||
| + | 待機ドライブの自動スピンダウン設定を試したくなるかもしれませんが、システムドライブしかないのであれば注意すべきです。スピンアップはドライブの寿命を縮めます。 | ||
| + | （SATA SSDを買うまでの）数ヵ月間、私は内蔵のPCI '' | ||
| + | ランダムリード要求についてはHDDより高速ですが、ランダムライトは非常に低速です。 | ||
| + | 加えて、SDカードは殆ど電力を食いません。 | ||
| + | USBフラッシュドライブを使う事も可能ですが、EHCI USBコントローラの消費電力に比べれば効果は限定的です。 | ||
| + | 私の2.5インチ日立製SATA HDDをスピンダウンすると、約1Wの削減です。 | ||
| + | 完全に取り外すと2Wの削減です。 | ||
| - | ==== 9. SATA ==== | ||
| + | ==== 9. SATA ==== | ||
| - | Comparing to PATA, SATA interface uses differential signaling for data transfer. To work properly it has to transmit pseudo-random scrambled sequence even when idle. As you understand, that requires power. But SATA implements two power saving modes: | + | PATAと比べると、SATAインタフェースはデータ転送に差動シグナルを用います。 |
| + | 正常動作のため、アイドル時でも疑似的なランダムスクランブルシーケンスを転送しなければなりません。 | ||
| + | お察しの通り、これは電力を要求します。 | ||
| + | しかしSATAは2つの省エネモードを実装しています：PARTIALとSLUMBERです。 | ||
| + | これらモードは、ホストとデバイの両方が対応していれば、どちらからでも有効にできます。 | ||
| + | PARTIALモードはスクランブル化を止めるだけで、ニュートラルなリンク状態を保ち、復帰時間は50～100マイクロ秒です。 | ||
| + | SLUMBERモードはインタフェースの電源を完全に落とし、各復帰時間は3～10ミリ秒です。 | ||
| - | The ata(4) | + | '' |
| + | '' | ||
| + | 1にするとドライブ自身の省エネ状態が開始されます。 | ||
| + | 2と3で、AHCI互換コントローラが毎コマンド完了後にPARTIAL/SLUMBERへの遷移を許可します。 | ||
| + | 新しい'' | ||
| + | これは4と5のモードもサポートし、性能劣化を最小化するモードです。 | ||
| + | SATA省エネモードはドライブのホットスワップを困難にすることに留意してください。なぜなら、リンクの電源が落ちている時、コントローラはドライブの存在を検出することが不可能だろうからです。 | ||
| - | In my case PARTIAL | + | 私の場合、PARTIALモードは0.5W、SLUMBERは0.8Wの削減です。 |
| - | ==== 10. USB ==== | + | ==== 10. USB ==== |
| + | 以下のコマンドを実行することで、USBデバイスは個々に省エネモードの切り替えができます： | ||
| - | USB devices can individually be switched to and from power save mode by running the following commands: | + | < |
| - | + | # このコマンドはデータトラフィックがない間のUSBデバイスの自動サスペンドを有効にします | |
| - | # This command will enable automatic suspend of the USB device when no data traffic is pending. | + | |
| usbconfig -d X.Y power_save | usbconfig -d X.Y power_save | ||
| + | </ | ||
| - | # This command will disable | + | < |
| + | # このコマンドは与USBデバイスの省エネモードを無効にします | ||
| usbconfig -d X.Y power_on | usbconfig -d X.Y power_on | ||
| + | </ | ||
| - | The default for all devices except | + | USBハブを除く全てのデバイスのデフォルト値は" |
| + | USBデバイスの省エネモードを有効にする前に、デバイスのコンフィギュレーションでスクリプタ、すなわち" | ||
| + | USBのサスペンド/ | ||
| + | 省エネ機能は同様にUSBデバイス/ガジェットモードにも適用可能です。 | ||
| - | ==== 結果==== | ||
| - | So what have I got? To monitor real system power consumption I am using information provided by ACPI battery via acpiconf -i0 command: | + | ==== 結果 ==== |
| - | Original system: | + | 私は何を得たでしょうか？ |
| + | 実際のシステム消費電力をモニタするため、'' | ||
| + | 元のシステム： | ||
| + | < | ||
| Design capacity: | Design capacity: | ||
| Last full capacity: | Last full capacity: | ||
| 行 277: | 行 330: | ||
| Present rate: 1621 mA | Present rate: 1621 mA | ||
| Voltage: | Voltage: | ||
| + | </ | ||
| - | Tuned system: | + | チューニングしたシステム： |
| + | < | ||
| %acpiconf -i0 | %acpiconf -i0 | ||
| Design capacity: | Design capacity: | ||
| 行 298: | 行 352: | ||
| Present rate: 826 mA | Present rate: 826 mA | ||
| Voltage: | Voltage: | ||
| + | </ | ||
| - | So I have really doubled my on-battery time by this tuning - 4:47 hours instead of 2:24 with default settings. Cooling fan, previously running all the time, now idle most of time, when system is idle. Preinstalled vendor-tuned | + | このチューニングにより、なんとバッテリー駆動時間が2倍、デフォルト設定の2時間24分から4時間47分になりました。 |
| + | 冷却ファンは以前は常に動いていましたが、今ではシステムがアイドル時は殆ど待機状態です、 | ||
| + | 同じシステムのメーカーチューニングされたプリインストールのWindows XPでは、最大3時間20分ということでした。 | ||
| -- Alexander Motin | -- Alexander Motin | ||
| + | |||
| + | ===== 翻訳履歴 ===== | ||
| + | |||
| + | * 2019-12-01 [[https:// | ||
| + | * 2015-03-23 翻訳開始 | ||
| + | |||