シール貼り付け期間の最終日、６月３０日になって、ようやく３００ポイントに到達しました。
ながい道のりだった。
なんか、もう、モチベーションがね・・・
すでにレジの脇には、明日からはじまるスヌーピーフェアの台紙が用意されていました。これまでは準備運動。本番は、明日から！
■ 過去記事
pochiが周波数も比例された。
そもそもきょうはにょほほのハングへコントロールしたかも。
かつきょうpochiがツールまでパワー消費♪
*このエントリは、BlogPet(ブログペット)の「pochi」が書きました。
そもそもきょうはにょほほのハングへコントロールしたかも。
かつきょうpochiがツールまでパワー消費♪
きょう、マウントも移行されたみたい…
*このエントリは、B l o g P e t(ブログペット)の「p o c h i」が書きました。
*このエントリは、BlogPet(ブログペット)の「pochi」が書きました。
smartmontools（/usr/ports/sysutils/smartmontools）と、rrdtool（/usr/ports/net/rrdtool）と、ちょろっと書いたperlスクリプトとを組み合わせて、定期的にSMARTのAttribute値を採取し、グラフにしてみました。
■ 関連記事
■ １時間あたりのグラフ
Spin Up Time
・・・ディスクが回転を始めた時刻？増加していない。
Seek Time Performance
・・・シークタイム（の何？）
Power On Minutes
・・・電源が入っている時間（分）？
Hardware ECC Recovered
・・・誤り訂正符号（ECC）により修正された回数？
Soft Read Error Rate
・・・一時的なリードエラー（たまたまエラーになっただけでもう一度リードすれば正常）の回数？
Temperature Celsius
・・・温度（単位は摂氏）
■ １日あたりのグラフ
Spin Up Time
Seek Time Performance
Power On Minutes
Hardware ECC Recovered
Soft Read Error Rate
Temperature Celsius
この波形をながめていて、なんとなく想像できること。
- どうやら、Seek Time Performaceは、どんどんカウントアップするカウンタになっていて、ある一定値に達すると、リセットされているらしい。
- Hardware ECC Recovered、Soft Read Error Rateも、アップカウンタなんだけど、どちらかが、先に天井に達すると、両方とも同時にリセットされているらしい。
- マシンが遊んでいるときは、滑らかに上昇し、portupgradeを実行中など、ディスクがガリガリ動いているようなときは、密な、ギザギザ波形（三角波だね）が現れていた。
この属性値の正確な意味、つまり、smartctlコマンドで表示される、Attributeの値の意味が知りたくて、smartctlコマンドのマニュアルを読んでみました。どうやら、結論は、
ハードディスクのベンダーが勝手に決めた値
ってことらしいです。とはいえ、なかなか興味ぶかげな値です。せっかくなので、非常にラフですが、日本語に訳しておきました。
-A, --attributes
Prints only the vendor specific SMART Attributes. The Attributes are numbered from 1 to 253 and have specific names and ID numbers. For example Attribute 12 is "power cycle count": how many times has the disk been powered up.
-A, --attributesオプションを指定すると、ベンダー固有のSMART属性のみを表示する。この属性には、１から２５３までの番号が割り振られていて、特定の名前とID番号がついている。たとえば、属性１２は、「power cycle count」であり、ディスクの電源をこれまで何回入れたか、を表す。
Each Attribute has a "Raw" value, printed under the heading "RAW_VALUE", and a "Normalized" value printed under the heading "VALUE". [Note: smartctl prints these values in base-10.] In the example just given, the "Raw Value" for Attribute 12 would be the actual number of times that the disk has been power-cycled, for example 365 if the disk has been turned on once per day for exactly one year. Each vendor uses their own algorithm to convert this "Raw" value to a "Normalized" value in the range from 1 to 254. Please keep in mind that smartctl only reports the different Attribute types, values, and thresholds as read from the device. It does not carry out the conversion between "Raw" and "Normalized" values: this is done by the disk's firmware.
各属性には、「Raw（生）」値というのがあり、これは、「RAW_VALUE」と書かれた見出しの下に表示され、また、「Normalized（正規化）」値が、「VALUE」見出しの下に表示される。［注：smartctlでは、10進数で表示する］。先ほどの例で言えば、属性１２のRaw値は、おそらくは、ディスクの電源が実際に入れられた回数であり、たとえば、ちょうど過去１年間にわたって、毎日１回、電源を入れたのなら、３６５になる。各ベンダーは、ベンダー固有の変換アルゴリズムにしたがって、Raw値を、１から２５４までの間のNormalized値へ変換する。注意して欲しいのだが、smartctlは、デバイスから読み出したままの、属性タイプ、値、閾値をレポートしている。Raw値とNormalized値との間の変換処理は、smartctlでは行っておらず、ディスクのファームウェアによって変換されている。
The conversion from Raw value to a quantity with physical units is not specified by the SMART standard. In most cases, the values printed by smartctl are sensible. For example the temperature Attribute generally has its raw value equal to the temperature in Celsius. However in some cases vendors use unusual conventions. For example the Hitachi disk on my laptop reports its
power-on hours in minutes, not hours. Some IBM disks track three
temperatures rather than one, in their raw values. And so on.
Raw値を、物理的な単位の値へ変換する方法は、SMARTの規格では規定されていない。たいていの場合、smartctlで表示される値は、感覚的に理解できる。たとえば、温度の属性なら、一般に、Raw値は、摂氏での温度である。しかし、めずらしい表現方法を用いるベンダーがたまにいる。たとえば、私のラップトップPCに入っている日立のディスクでは、power-on hours（パワーオン時間）の単位が、時間ではなく、分でレポートされる。IBMのディスクのうちの一部では、１つではなく、３つの温度を、Raw値で記録している（訳注：訳が間違ってるかも）。などなど。
Each Attribute also has a Threshold value (whose range is 0 to 255) which is printed under the heading "THRESH". If the Normalized value is less than or equal to the Threshold value, then the Attribute is said to have failed. If the Attribute is a pre-failure Attribute, then disk failure is imminent.
また、各属性には、閾値（０から２５５までの範囲）があり、「THRESH」見出しの下に表示される。もしも、Normalized値が、閾値以下の場合、その属性は、failedであるという。その属性がpre-failure属性（訳注：pre-failureについてはこの後に説明がある）の場合、そのディスクは、切迫した故障状態である。
Each Attribute also has a "Worst" value shown under the heading "WORST". This is the smallest (closest to failure) value that the disk has recorded at any time during its lifetime when SMART was enabled. [Note however that some vendors firmware may actually increase the "Worst" value for some "rate-type" Attributes.]
各属性には、「Worst」値というものあり、「WORST」見出しの下に表示される。これは、ディスクのSMART機能が有効にされていて、ディスクが使用されている期間中に記録された、最小（故障する寸前の）値である。［注：ベンダーのファームウェアによっては、「rateタイプ」の属性の「Worst」値を増加させる場合がある］。
The Attribute table printed out by smartctl also shows the "TYPE" of the Attribute. Attributes are one of two possible types: Pre-failure or Old age. Pre-failure Attributes are ones which, if less than or equal to their threshold values, indicate pending disk failure. Old age, or usage Attributes, are ones which indicate end-of-product life from old-age or normal aging and wearout, if the Attribute value is less than or equal to the threshold. Please note: the fact that an Attribute is of type 'Pre-fail' does not mean that your disk is about to fail! It only has this meaning if the Attribute's current Normalized value is less than or equal to the threshold value.
smartctlが表示する属性の表には、属性の「タイプ」も表示される。属性には、Pre-failureと、Old ageの、２つのタイプがある。Pre-failure属性の場合、閾値以下なら、ディスクの故障は保留中であることを意味する。Old ageまたはusage属性の場合、閾値以下なら、製品寿命であることを意味する（訳注：訳がよくわからない）。注意してほしいのだが、属性がPre-failになっていても、そのディスクが故障しかけているという意味ではない。現在のNormalized値が、閾値以下になったときだけ、故障寸前という意味になる。
If the Attribute's current Normalized value is less than or equal to the threshold value, then the "WHEN_FAILED" column will display "FAILING_NOW". If not, but the worst recorded value is less than or equal to the threshold value, then this column will display "In_the_past". If the "WHEN_FAILED" column has no entry (indicated by a dash: '-') then this Attribute is OK now (not failing) and has also never failed in the past.
属性のNormalized値が閾値以下になると、「WHEN_FAILED」見出しの列に、「FAILING_NOW」と表示される。それ以外の場合で、worst値が閾値以下なら、この列には「In_the_past」と表示される。「WHEN_FAILED」列に何の値も入っていない場合（「-」ダッシュで表示される）、その属性は今はOK（故障はしていない）であり、過去にも故障したことはない。
The table column labeled "UPDATED" shows if the SMART Attribute values are updated during both normal operation and off-line testing, or only during offline testing. The former are labeled "Always" and the latter are labeled "Offline".
表の「UPDATE」列に、「Always」と表示される場合、通常動作状態およびオフライン・テスト中に、属性の値が更新されることを意味し、「Offline」の場合は、オフライン・テストのときのみ更新されることを意味している。
So to summarize: the Raw Attribute values are the ones that might have a real physical interpretation, such as "Temperature Celsius", "Hours", or "Start-Stop Cycles". Each manufacturer converts these, using their detailed knowledge of the disk's operations and failure modes, to Normalized Attribute values in the range 1-254. The current and worst (lowest measured) of these Normalized Attribute values are stored on the disk, along with a Threshold value that the manufacturer has determined will indicate that the disk is going to fail, or that it has exceeded its design age or aging limit. smartctl does not calculate any of the Attribute values, thresholds, or types, it merely reports them from the SMART data on the device.
というわけで、まとめ。
Raw属性値は、摂氏の温度、時間、スタート・ストップ回数といった、物理的な意味の値の場合がある。ディスクの製造メーカーは、各自が知っているディスクの動作や故障モードといった詳細な知識に基づいて、Raw値を、１～２５４の範囲のNormarize値へ変換している。Normalized値の、現在の値と、Worst値（最悪値。これまでで記録した最小値）、そして、閾値が、ディスクに記録されている。閾値は、ディスクが故障しそうか、設計寿命か、使用期限か、などを判断するための値であり、メーカー側で決めたものである。smartctlは、属性の値、閾値、タイプなどを変換処理はしておらず、単に、デバイスのSMARTデータをそのままレポートしている。
Note that starting with ATA/ATAPI-4, revision 4, the meaning of these Attribute fields has been made entirely vendor-specific. However most ATA/ATAPI-5 disks seem to respect their meaning, so we have retained the option of printing the Attribute values.
ATA/ATAPI-4 revision 4のときから、属性のフィールドの意味は、ベンダー固有であると決めれていた。しかしながら、ほとんどのATA/ATAPI-5 ディスクがこれらの意味を尊重しているようなので（訳注：？？？）、この属性値を表示するためのオプションを残したままにしている。
For SCSI devices the "attributes" are obtained from the temperature and start-stop cycle counter log pages. Certain vendor specific attributes are listed if recognised. The attributes are output in a relatively free format (compared with ATA disk attributes).
SCSIデバイスの場合、属性は、temperatureとstart-stopサイクルカウンタのログ・ページから読み出される（訳注：？？？）。認識可能ないくつかのベンダー固有の属性も、リストされる。属性は、（ATAディスクの属性と比べると）ややフリー・フォーマットで表示される。
今日、プリンタで印刷しようとして、lprコマンドやlpqコマンドを実行すると、今まで見たことのないエラーが出ることに気がつきました。
こんなエラーです。
% lpr -Pプリンタ ファイル.ps
lpr: Connection refused% lpq -Pプリンタ
lpq: Unable to connect to server
環境変数LANGがja_JP.eucJPだったりすると
% lpq -Pプリンタ
lpq: サーバに接続できません
しばらく、あちこち調べまわって、意外なところに問題が見つかりました。
% which lpr
/usr/local/bin/lpr
% which lpq
/usr/local/bin/lpq
なんと、/usr/local/binですか。普通は、/usr/binのはずです。
こいつは何者だ！？と調べてみると・・・
% pkg_which /usr/local/bin/lpq
cups-base-1.2.0_2
はぁ・・・
どうやら、portupgradeで、cups-baseを最新版にアップデートしたところ、lpr、lpq、lprmという、/usr/binにある印刷関係のコマンドと同名のコマンドが、/usr/local/binにインストールされてしまった、ということでした。
旧バージョンのときは、これらのコマンドはインストールされていなかったのですが、今回から入るようになってしまったようです（まさかパッケージングのミスではないですよね？）。
とりあえず、環境変数PATHを/usr/binを先にして回避することにしました。
☆ ☆ ☆ ☆ ☆
しかし、これもいい機会だということで、CUPSのセットアップでもしようかと思い、ドキュメントを見ながら、試すことにしました。
「えーと、次に、cupsdを実行するのですか。」
・・・cupsdを動かしたら、
/etc/printcapを上書きされてしまいました。
泣く泣く、バックアップのほうから、/etc/printcapを復活させました。
これまでCUPSは使わずに、昔ながらのLPR、LPDでの印刷を行っていたのですが、そろそろ、CUPSを使うようにしたほうがいいんでしょうかね？
ここ数日、急に、暑くなってきました。
あぁ、暑い、あつい、熱い、といえば、パソコンも暑くなる原因の１つ。ひどいときには、ファンから、まるでドライヤーのように熱風が吹き出していたり・・・
パソコンが何十台もある部屋があるんですが、1台から出る熱が少なくても、台数が増えてくると、たまりません。パソコンから出た熱をさますために、クーラーががんばるので、クーラーの電力消費量も増えますし、そもそも、熱の発生源であるパソコン自体が、熱の分だけ電力を消費しているわけです。電気を大切にね、と。
というようなわけで、最近のパソコンには、とくになんの仕事もしていないときは、CPUのクロック周波数を低くしたり、CPUの電源電圧を下げたりすることで、電力消費量を減らす仕組みが用意されています。
こういう機能は、一見、バッテリで動くノートパソコンだけの専用機能かと思いがちですが、実は、最近のデスクトップパソコンの多くでも、利用可能になっています。
さてさて、FreeBSDの場合、そのへんの仕組みは、どうなってんのよ？と思い、調べてみました。
わかったこと。
インストールしたまんまの状態では、何もやってません。
おしまい。
なんと、そうだったんですかっ！？
一応、現在の最新バージョンである、FreeBSD 5.5、FreeBSD 6.1の両方で、機能は用意されているのですが、使うように設定しない限り、機能は無効化されています。
というわけで、設定方法から・・・
■ FreeBSDで、消費電力を減らすための設定
/boot/loader.confに、以下の1行を追加します。
cpufreq_load="YES"
/etc/rc.confに、以下の1行を追加します。
powerd_enable="YES"
そして再起動するか、もしくは、以下のようにコマンドを実行して、即座に試してみることも可能のようです。
# kldload cpufreq
# powerd
■ ちょっと待ったぁ！
やるまえに、大切な注意事項のお知らせから。
運が悪いと、OSごとフリーズします・・・
私の場合、数台のデスクトップPCで試してみて、２台でフリーズしました。
だから、デフォルトではこの機能が有効になっていないのかもしれません。
ハングしてもいいマシンで、ハングしても大丈夫な状態にして（たとえば大容量のファイルシステムはumountしておくか、read only mountにしておく）、試しましょう・・・えぇ、私は大失敗しましたから・・・
● その動かなかった例とは・・・
- 1台は、Xeonが2個のってて、かつHyperThreadingが有効になっているマシン。HyperThreadingを無効にしたら、フリーズしなくなりました
- もう1台は、Pentium4が2個のってて、HyperThreadingは無効になっていたマシン。当初、大丈夫そうに見えて、しばらくしたら、急にフリーズしました
SMPになっていると、なんか問題があるんでしょうかねぇ？
● 動いた例
- Athlon64な自作マシン。クロック周波数も変化しますし、電圧も変化していました。
- PentiumM 1000MHz（いわゆるBanias）なノートパソコン。クロック周波数が変化することは確認できましたが、電圧の変化は確認できませんでした（たぶん変化してるんじゃないかな）。
- Pentium4 3GHzなデスクトップパソコン。周波数は変化しましたが、電圧は変化しませんでした。もともと電圧を変化させる機能が無いものかも？
- Xeon 3.6GHzが2個のったPCワークステーション（前述のやつで、HyperThreadingは無効にしている）。周波数は変化しましたが、電圧は変化しませんでした。電圧を変化させる機能があるっぽいのですが、FreeBSDのデバイスドライバが対応していない？
■ ちょっと詳しい話
cpufreqというデバイスドライバが、CPUの処理性能を変化させるインターフェイスになっていて、その裏には、AMDのPowerNow!やCool'n'Quietとか、IntelのEnhanced SpeedStepとかのドライバが実働部隊として控えていて、実際に、クロック周波数や電源電圧を変化させる仕事をしているようです。
powerdというデーモンが、OSの負荷状況に応じて、CPUの処理性能を上下させたりしています。特に重いプログラムを実行していない限り、CPUのクロック周波数が、どんどん下がっていきます。プログラムを実行すると、即座に、元のフルパワーで動き出します。
現在のCPUのクロック周波数は、次のようなコマンドでわかります。
% sysctl -a dev.cpu.0.freq
dev.cpu.0.freq: 1000
この場合、1000となっているので、たぶん、1000MHzのことなんでしょう。
ところで、よくわかってないのですが、CPUが2個あっても、dev.cpu.1.freqってのはでてきません。もしも、CPUが2個とも、同じクロック周波数で動いているとすれば、まあ、1個だけでいいわけですが・・・いまどきのでも、まだ、個別に変えられないんでしたっけ？
さてさて、なにか重いプログラムを実行させておいてから、もう一度見ると
% sysctl -a dev.cpu.0.freq
dev.cpu.0.freq: 2400
ちゃんと、フルパワーで処理しています。
ところで、消費電力は、クロック周波数に比例し、電源電圧の２乗に比例します。たとえば、クロック周波数が2.4GHzから1GHzへ落ちて、電圧が1.25Vから1.10Vへ落ちたとすると、
(1000/2400)*(1.1/1.25)^2
.32266666666666666666
ってことで、消費電力は、元の３２％にまで、削減されます。もっとも、実際には、回路構成とか（clock gatingとか）いろいろな要因で、理論計算式からは誤差が生じますし、パソコンの中で、電力を消費しているのは、CPUだけでなく、ほかにもいろいろあります（ビデオチップとか、チップセットとか、ハードディスクとか、あとロスしている電力とか・・・）。あと、単位の、電力と電力量を間違わないようにね・・・中学校の理科でならうんだっけ？高校？
以下は、MBMONというツールと(/usr/ports/sysutils/mbmonにあります)、rrdtoolというツール（同じく/usr/ports/net/rrdtool）を組み合わせて、CPUなどの温度や、ファンの回転数などを記録しておき、グラフにしたものです。
- 横幅いっぱいで、1日分です。
- クロック周波数は、計測してませんでした。
- 上に上がっている部分が、CPUがフルパワーで回っているときです。
温度
CPUの電源電圧
ファンの回転数
● その他
# sysctl debug.cpufreq.verbose=1
とやると、CPUのクロック周波数が変化している様子が、ログにでてきます。
Jun 27 11:27:20 athlon64 kernel: cpufreq: get returning known freq 2400
Jun 27 11:27:20 athlon64 kernel: cpufreq: get returning known freq 2400
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 2400 at head
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 2200 after 2400
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 2000 after 2200
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 1800 after 2000
Jun 27 11:27:20 athlon64 kernel: cpufreq: adding abs setting 1000 after 1800
かなり大量にでてくるので、1度見て満足したら、さっさと止めましょう。
# sysctl debug.cpufreq.verbose=0
■ いろいろ試した例
● Athlon64なマシン
FreeBSD 5.5-STABLE #1: Wed Jun 7 17:40:23 JST 2006
root@ほげ:/usr/src/sys/i386/compile/ほげ
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 Processor 3400+ (2403.09-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0xfc0 Stepping = 0
Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
AMD Features=0xe0500000<NX,AMIE,LM,DSP,3DNow!>
real memory = 3220373504 (3071 MB)
avail memory = 3150012416 (3004 MB)
（省略）
powernow0: <Cool`n'Quiet K8> on cpu0
となってて、sysctlでみると、こんなかんじ。
ほげ# sysctl -a | grep cpu
kern.threads.virtual_cpu: 1
kern.ccpu: 1948
cpu0: <ACPI CPU> on acpi0
powernow0: <Cool`n'Quiet K8> on cpu0
kern.smp.maxcpus: 1
kern.smp.cpus: 1
debug.cpufreq.lowest: 0
debug.cpufreq.verbose: 0
hw.ncpu: 1
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
machdep.cpu_idle_hlt: 1
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU1
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1000
dev.cpu.0.freq_levels: 2400/89000 2200/72000 2000/53000 1800/39000 1000/22000
dev.acpi_perf.0.%parent: cpu0
dev.powernow.0.%parent: cpu0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
● Xeonが2個なマシン
FreeBSD 6.1-STABLE #7: Tue Jun 13 15:57:03 JST 2006
root@ほげ２:/usr/src/sys/i386/compile/ほげ２
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.16-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf41 Stepping = 1
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x659d<SSE3,RSVD2,MON,DS_CPL,EST,TM2,CNTX-ID,CX16,<b14>>
AMD Features=0x20100000<NX,LM>
Logical CPUs per core: 2
real memory = 3488481280 (3326 MB)
avail memory = 3409637376 (3251 MB)
ACPI APIC Table: <ふがふが>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 6
（略）
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 122d0000122d
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 122d0000122d
device_attach: est1 attach returned 6
p4tcc1: <CPU Frequency Thermal Control> on cpu1
どうやら、Enhanced SpeedStepが使えていないようです。ソースファイルは
/usr/src/sys/i386/cpufreq/est.c
が該当するようなので、暇があれば、いろいろ調べたり試したりしてみましょうかね。
% sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 451
dev.cpu.0.freq_levels: 3614/-1 3162/-1 2710/-1 2258/-1 1807/-1 1355/-1 903/-1 451/-1
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
● PentiumMなノートパソコン
OSは、上記とおなじときの、6.1-STABLE。
CPU: Intel(R) Pentium(R) M processor 1000MHz (999.97-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x695 Stepping = 5
Features=0xa7e9f9bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE>
Features2=0x180<EST,TM2>
（略）
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
となっていて、sysctlで見ると、こんなかんじ。
% sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 75
dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1
% sysctl dev.est
dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.%driver: est
dev.est.0.%parent: cpu0
dev.est.0.freq_settings: 1000/-1 900/-1 800/-1 600/-1
% sysctl dev.p4tcc
dev.p4tcc.0.%desc: CPU Frequency Thermal Control
dev.p4tcc.0.%driver: p4tcc
dev.p4tcc.0.%parent: cpu0
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
残念ながら、
% mbmon -d
ioctl(smb0:open): No such file or directory
SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM available on it!!
No Hardware Monitor found!!
InitMBInfo: Bad file descriptor
となってしまって、mbmonで、CPUの電圧を知ることはできませんでした。
portupgradeとかで負荷をかけたり、いろいろ使ってみて、体感としては、この機能を有効にする前よりは、ファンが高速回転する時間が少なくなったような気がします。気のせいかも。
■ ほかのOSはどうなの？
Windows用のユーティリティは、ちょこっとさがせば、すぐ見つかるでしょう・・・
とりあえず、Linuxな、Fedora Core 5の場合を、ちょっとだけ調べてみました。
マシンは、ラックマウントな1Uサーバで、CPUは、Opteron 250が2個。
実は、最新のBIOSへアップデートしたら、PowerNow!が使えるようになりました。アップデート前は、ACPIまわりがおかしかったっぽいです。
ブート時のログに、こんな風に表示されます。
powernow-k8: Found 2 AMD Athlon 64 / Opteron processors (version 1.60.0)
powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0x2 (1500 mV)
powernow-k8: 1 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
powernow-k8: 3 : fid 0xa (1800 MHz), vid 0xc (1250 mV)
powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0xe (1200 mV)
cpu_init done, current fid 0x10, vid 0x2
powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0x2 (1500 mV)
powernow-k8: 1 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
powernow-k8: 3 : fid 0xa (1800 MHz), vid 0xc (1250 mV)
powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0xe (1200 mV)
cpu_init done, current fid 0x10, vid 0x2
そして、普通にFedora Core 5をインストール（Core 3からアップグレード）しただけなんですが、勝手にcpuspeedというのがインストールされて、勝手に動いていて、知らないうちに、よきにはからって、CPUの周波数と電圧をコントロールしてくれていました（xmbmonで、その様子を確認）。
Linuxでは、「/sys/devices/system/cpu/cpu0/cpufreq/」とか「/sys/devices/system/cpu/cpu1/cpufreq/」以下で、CPUのパフォーマンスをコントロールできるようになっているようです。
% ls /sys/devices/system/cpu/cpu1/cpufreq/
/sys/devices/system/cpu/cpu1/cpufreq:
affected_cpus scaling_cur_freq
cpuinfo_cur_freq scaling_driver
cpuinfo_max_freq scaling_governor
cpuinfo_min_freq scaling_max_freq
scaling_available_frequencies scaling_min_freq
scaling_available_governors scaling_setspeed
こんなふうにして、CPUのクロック周波数を確認できます。
（現在の周波数）
# cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq
1000000
（設定可能な最高周波数）
# cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
2400000
（設定可能な最低周波数）
# cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_min_freq
1000000
ちなみに、「/proc/cpuinfo」でも、今の周波数が見えました。
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 250
stepping : 10
cpu MHz : 1000.000
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 2004.69
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 250
stepping : 10
cpu MHz : 1000.000
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 2004.69
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
なんか、海岸で、くまさんがいるんです。
しかも、あぐらをかいで。
で、何かを食べてるんですよね。
むしゃ むしゃ
「おひとついかが？」
「お、こりゃどうも」
ブルーベリーって、海岸にはえてるのでしょうか？
サプリメントでも、流行してますからねぇ。眼にいいとか。
この人は、ムルアカさん・・・じゃないか。
このおっさんは、くまさんからもらっておきながら、自分が木からつんだ実のほうがでっかいぞ、と見せつけたりして、かなり礼儀知らずなところがあります。
というわけで、今度は、「ブルーベリー狩り」だそうです。
ここのＣＭって、以前にも、「でんどろびゅ～む」がずっと頭に残ってしまう、不思議な雰囲気のがありました。
今度は、オーソドックスな、普通の「金ちゃんヌードル」。
これが、生まれて初めて食べたインスタントラーメン。やっぱり、これが一番好きかも。
金ちゃんラーメンという袋入りタイプのがあるみたいなんですが、そちらは、見たことがないです。静岡県内でも売ってるのかな？「金ちゃんねぎラーメン」とかいうカップ入りのなら、食べた記憶がありますが、ウェブで見られるパッケージデザインが、記憶の中のものとはまったく違うんです。
■ 前回の記事
犬に起こされ、朝の６時台に、散歩に連れ出されました。
で、おまえは、また寝るのか！？
数週前のモーニングに掲載されていた「誰も寝てはならぬ （Nessun dorma）」 （サラ イネス著・・・「大阪豆ごはん」と同様に、好きな人にはたまらない、都こんぶみたいなマンガ）にて、飼い猫が、人が読んでいる新聞に乗っかってくるという描写があったんですが、こいつも、しますね。
じっくりと新聞を読んでいるときに、どこからかやってきて、目の前に、横たわってくれます。
彼らにとって、人間が文字を読むという行為を理解できないはずだから、単に、視線が集中している範囲に入り込めば、かまってもらえるとか、思っているのでしょうか。
はなをかんだら、なぞの物体が飛び出してきた。
夕方になって、ようやく動けるようになった。
用事があったので、実家へ。
こいつは元気。
