Re: Leaving the Desktop Market

[Kevin Oberman <rkoberman@gmail.com>]

On Sat, May 3, 2014 at 9:49 PM, Adrian Chadd <adrian@freebsd.org> wrote:

> こんにちは，
> 
> まぁ，ハードウェアは良くなったし，いろんな点で良くなりましたよ．私は
> speedstep や throttling などハードウェアから離れてて幸いだったですが，もし良
> けば C-states や 限定された周波数のステッピングに関する電源まわりについて御
> 教示いただければと思います．
> 
> それで，こんなことはどうなんでしょう:
> 
> * C states が利用できるなら - ちょっと C states を使ってみて cpu 周波数が全
> くステップしない;
>

C-states はすばらしい．C-states 同様に何かに関して行なっているだけだと推察し
ます．証明はできませんが，ロードに依存して C にして P-states を使うのに一票．

> * turboboost が利用できるなら - もしあまりにも長い間より高い周波数で CPU
> が動作することを確認できるなら，それを有効/無効にする．

ACPI が既に turboboost モード時のランタイムを制限していると思う．

> * 何かの方法で cpufreq を使う(アイドル時に 2/3 段階の周波数のステップダウン
> のだけ行なうような) - そして何故そのとうな決定をしたかのドキュメント(CPU X
> 上の eg, アイドル時の Y の計測, 電源消費は frequency=Z で最小になる);

P-states を使えるようにしたいなら CPUfreq を使って．Intel の良いエンジニアと
いうのは，与えられた CPU でそれらが設定された状態で何ができるのかを理解して
いると信じてますが．もちろん C-states だけは TCC やスロットリングではなく
cpufreq で使うべきだと．


> * ある温度カットオフに達っしたら低い周波数と tcc が作動することを確認するこ
> と;

ACPI で disable されないときはこれが自動的な動作だと教えられたが．

> * バギーにならないとみなされるなら筐体外で低い Cx 状態を使うのをデフォルトに
> する．低い C 状態が問題を起すような CPU は 2〜3 あるが最近のハードウェア
> (たとえば nehalem はそれ以降)は問題ない．
> 

スロットリング および TCC を取り除いたとすれば，＊どんな＊ CPU も C-state で
は Cmax が走らない理由は全くわかりません．私はこれまで C-states や P-states
に関して何の問題も無かった．あるとすれば同時にスロットリングおよび TCC を低
い値に設定したとき問題らしき現象が起ったくらいです．もし CPU がメチャ熱くなっ
て TCC が最低の p-state 速度の 25% 以下になったら，ハードウェアにとって{非常
に}^2マズイことになるでしょう．

> これらはもやもやと私の頭に渦巻いていたものです．
> 
> 
> 
> -a
> 
> 
> On 3 May 2014 21:16, Kevin Oberman <rkoberman@gmail.com> wrote:
> > On Sat, May 3, 2014 at 6:07 PM, Nathan Whitehorn <nwhitehorn@freebsd.org>
> > wrote:
> > >
> > > On 05/03/14 16:59, Kevin Oberman wrote:
> > > > On Sat, May 3, 2014 at 1:25 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> > > >
> > > > > Cx を dev.cpu.0 で取り得る可能な限り低い状態に設定してください．
> > > > > 
> > > > > 
> > > > 値は特に指定する必要はありません．C8 に設定してください．使用した最も低い値
> > > > が保証されます．rc.conf での正しいおまじないは "Cmax" です．
> > > > performance_cx_lowest="Cmax"
> > > > economy_cx_lowest="Cmax"
> > > > 
> > > > でも，もしラギーな性能を求めないなら，おそらく更に
> > > > hint.p4tcc.0.disabled=1
> > > > hint.acpi_throttle.0.disabled=1
> > > > を /boot/loader.conf に必要です．このスレッドの最初の方でも書いてたように，
> > > > 低い Cx 状態および TCC/スロットリングは全然うまくミックスできない．
> > > 
> > > TCC がデフォルトでオンなのは実際何か理由があるのかな? 反対のような気がするけ
> > > ど．
> > 
> > 
> > 本当にこれには何年も困ってるんだ．スロットリングは速かった．SpeedStep は電源
> > 管理で使えた全部に付いていたけど，それ以前のラップトップには付いてさえなかっ
> > たんだ．スロットリングはそれらの古いシステムのため何とか電源管理を確保する
> > 方法であると思われていた．Nate は FreeBSD の最初の電源管理を開発し，SST を初
> > めて組み込んだ．彼はスロットリングについてその性能の強化と SpeedStep のない
> > 古いラップトップへの何らかの機能の追加の両面について身を投じた．
> > 
> > 結局私にとっても SST が 2 つの性能レベルでのみ提供されたことで意味のあること
> > となった． 何もないところからの一つの改善だったが，実際には 1 つではなく多く
> > の改善があった．それはそれで十分だと我々の誰もが思わなかったことが大体の理由
> > だが，実際スロットリングには助けがいると信じていた．cpufreq がコミットされる
> > 前に Pentium 4 が出て，スロットリングがどうなるかを TCC に組み込んでみてみた
> > が，更にもっとクリーンになった．それで，利用できるなら TCC を，できないとき
> > はスロットリングを使うようにcpufreq を変更した．振り返ってみると，これはほと
> > んどムダだったが，その当時は意味のあることだった．
> > 
> > それからしばらくして，EST (true P-states) が出てきた．これは実際通常のアプリ
> > ケーション使用時には電力消費を抑えた．そのドライバはかなり早くに追加されたが
> > throttling/TCC は残された．その唯一の実際の効果は幾度となく "周波数" を CPU
> > パワーに追加させたことだ．そして，それは CPU 負荷が小さいときは電力消費を抑
> > えてより長く持たせ，忙しくなるとスピードアップにラグを生じさせた．
> > 
> > 次に C-states がやってきて，ほぼ同時に D-states が来た．Dx は極めて密接にハー
> > ドウェアとリンクしていて節約は限定的だったが，C-states は本物だった．これは
> > 本当に電源を節約したので大転換だった．不幸にも Cx が CPU lockup を起し，非常
> > に対話的な遅延が激しくなるという声が起り始めた．結局， Cx のデフォルト設定は
> > disable になった．この選択は全く間違っていた．これはその理由を何ら解析するこ
> > となく行なわれた．Cx は hanging システムで間違った動作をしたのでオフにされた．
> > 
> > その問題を解決するにはあまりにも時間が無かった．そのときこの問題が生じた私の
> > ラップトップは 800 MHz の最低 P-state の Pentium-M だった．Ass TCC と idle
> > clock は 100 MHz でちょうど有効であった．電源によってスピード調整する方法と
> > C-states を組合せれば，望みうる最も良い状態が酷い応答になる．最低レベルのア
> > イドル状態から抜け出すにはあまりにも遠回りな方法だった．それまで経験したこと
> > がなかったのでそんなハングは説明できないが，単純に TCC(およびスロットリング)
> > を切れば防げた．
> > 
> > 明かにやんなきゃいけないことは TCC を切って C-states を目一杯使うように思え
> > た．これは mav が FreeBSD の電源管理に関する大変素晴しい論文を出したときには
> > 更に疑いの余地なく明らかことであるというようにさえなった．もし電源管理に関し
> > て心配でそれを読んでらっしゃらない方は今すぐ↓を!
> > https://wiki.freebsd.org/TuningPowerConsumption
> > 
> > 何故 mav の指示がデフォルトにならなかったのかは全くもって理解できない．その
> > 原因の多くは，FreeBSD がまず第一にサーバ用途に開発されたことでありサーバでは
> > 電源の節約はあまり気に掛けないように思われるからだと思う．でも結果的にこれは
> > 変更されるのだが．
> > 
> > 私は歴史は大方正しいと思うが，v4 に立ち戻ってみれば，それは随分前のことだ．
> > 私はリタイアしで古いメールは見てないので間違ってる部分はあったと思う．間違い
> > だったら御免なさい．
> > -- 
> > R. Kevin Oberman, Network Engineer, Retired
> > E-mail: rkoberman@gmail.com
> 



-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com