2011/07/19

Intel SSDのE2/E3/E4

Intelの天野氏の置き土産について、自分でもよく分かってないが、とりあえず書き留めておく。

1. Endurance Monitoring #2

6/4に天野氏が最後のイベント出演をしたとき、Intel SSDの寿命予測に関してE9、あるいはHost Writesとはまた別の方法を説明していた。これが詳しく出ている記事(インテル天野氏が最後のイベント出演、Z68とSSDを語る)を見ると、これまで明らかでなかったSMARTのE2、E3、E4の意味が出てくる。

天野氏の資料によれば、
#2: Intel Timed Media Wear metric
- Allows user or system designer to evaluate the endurance wear rate for a proposed application through following SMART attributes
E2h/226 (Timed Workload Media Wear Indicator)
E3h/227 (Timed Workload Host Reads Percentage)
E4h/228 (Timed Workload Timer)

これは現在あるSSDの残り寿命がどれだけあるかを見るというより、ある負荷を与えたときにどれぐらい消耗するかを見るもののようで、
SMARTMON* tool can be used to report all SMART attributes using the following steps
- At command prompt, enter the following to list attributes:
smartctl -a /dev/hdx
- Before using a workload, enter the following to reset the E2, E3 and E4 attributes:
smartctl -t vendor,0x40 -a /dev/hdx
This issues a SMART EXECUTE OFFLINE IMMEDIATE SUBCOMMAND 0x40
- Run your workload for at least 60 minutes(できれば2時間)
- Power-cycle the system(電源を入れなおし)
- Re-enter this command to get the new values for E2, E3, and E4:
smartctl -a /dev/hdx
(注)丸括弧内は、元はIntel内部の資料だったものに天野氏が書き加えたものっぽい。

この「smartctl -a /dev/hdx」はドライブの情報を見るコマンドなので、まずこれでチェックした後で、「smartctl -t vendor,0x40 -a /dev/hdx」でE2、E3、E4をリセットし(たぶん0になる)、負荷を与えて再起動した後、再度「smartctl -a /dev/hdx」で変化を見ろ、という話(注)らしい。

(注)記事のキャプションでは少し違うことが書いてあるが、どうも分かってない感じがするので、資料の記述だけを信じる。

例として、E2が22、E3が99、E4が981のときは以下のようになる。
% Media Wearout during this run = 22(E2) /1024 = 0.021%
Work Ratio = 99(E3) % Read/Write
Workload Timer = 981(E4) mins
Lifetime using this specific workload 100% of the time 24/7 = 8.9 Years

981分間の消耗率が0.021%ということから計算して(この負荷だけをかけ続けた場合の)寿命は8.9年になるとのこと。一応計算してみると、

{100 ÷ [22/1024 ÷ 981](分当たりの消耗率(%))}(全消耗にかかる分数) ÷ {60 × 24 × 365}(年間の分数) ≒ 8.687422167(全消耗にかかる年数)

……。数字が合わないが、22/1024 ≒ 0.021484375を0.021に切り下げてから計算すると、

{100 ÷ [0.021 ÷ 981](分当たりの消耗率(%))}(全消耗にかかる分数) ÷ {60 × 24 × 365}(年間の分数) ≒ 8.887801696(全消耗にかかる年数)

合った。

いずれにせよ、E3はこの計算には入ってこない。「書き込みの割合が増えると耐久性は一気に下がる」というのは、E3が下がる=書き込みの割合が上がる負荷のときは、逆にE2は上がるという逆相関関係の意味だろうか。

2. 実験

さて、手元のX25-M G2 80GBで試してみる。コマンドプロンプトを管理者として開き、smartmontoolsで「smartctl -t vendor,0x40 -a /dev/sda」を実行(「smartctl -a /dev/sda」で表示されるものも全て入っている)。

このSMARTの部分は、226(E2)、227(E3)、228(E4)とも65535になっている。ATTRIBUTE_NAMEは、天野氏の資料ではHDDと同じだったが、この最新版(5.41-1)ではIntel SSDに対応しているようで、資料とほぼ同じ名前が短縮されたものになっている。

これはsmartmontoolsのデータベースであるdrivedb.hにあるもので、この中を見るとIntelの情報は伝わっていることが分かる。
"-v 226,raw48,Workld_Media_Wear_Indic " // Timed Workload Media Wear Indicator (percent*1024)
"-v 227,raw48,Workld_Host_Reads_Perc "  // Timed Workload Host Reads Percentage
"-v 228,raw48,Workload_Minutes " // 226,227,228 can be reset by 'smartctl -t vendor,0x40'

最後の部分では、「SMART EXECUTE OFF-LINE IMMEDIATE subcommand 0x40」に成功しているように見える。

が、この後再起動しようと何をしようと65535の数字は全く変わらなかった。このThinkPad X61s上のWindows 7 64bitのSATAのドライバをMicrosoftの標準ドライバ(6.1.7601.17514)とIntelのドライバ(10.1.0.1008)の間で変えたり、PATA(Compatibilityモード)に設定したりしても、効果なし。

念のため、CrystalDiskInfo(4.0.2a)で見た場合はこうなる。

E2、E3、E4はともにFFFFで、この16進数を10進数にすれば65535になるので、smartmontoolsと同じ(見ているデータが同じなのだから当然だが)。

あえて推測すれば、この4桁の16進数はどれも既に上限に達しているので、もう変わりようがない、ということではないかと……。これをリセットできない以上、先に進みようがない。

ということで、よく分からないまま終わる。

[追記1]

320シリーズのProduct Specificationの追補(Intel Solid-State Drive 320 Series Enterprise Server/Storage Application Product Specification Addendum)にはE2、E3、E4の説明があったので、320シリーズだけで有効なのかもしれない。

また、その説明によれば、値がFFFFなのは標準値(normalized value)ではそうなっているというだけらしい。

[追記2]

CrystalDiskInfo(4.1.0)からE2、E3、E4の名前に対応されているので補完。

日本語表記もばっちり。それぞれの詳細な意味は320シリーズの追補を読んでもらうということで。

2011/07/17

マウス三台

クリックボタンがおかしくなったVX-Nanoの交換機としてM905が来たので、Logicoolマウスを比較してみる。右がM905、左がVX-Nano、奥がM555b。

1. 重量

M905を空の状態で持ち上げると、VX-Nanoに慣れた手には重さを感じた。重量を電池を入れた状態で比較すると、以下のようになる。
本体
(レシーバー、
電池抜き)(g)
本体+
単4×1
(g)
本体+
単4×2
(g)
本体+
単3×1
(g)
本体+
単3×2
(g)
M9058499114111136
VX-Nano73-95--
V550 Nano69-97-117
M555b68-96-116
(注)単4はアダプターを含む(VX-Nanoを除く)。計測したときの電池のブランドが違うので、電池の重量にズレがある。

M905はマウス単体で他より11~18g重いので、単3×2のフル状態だと結構ずっしり来る。ただ、他と違って1本でも動作するので、最軽量の単4×1の状態であれば99gと、他の最軽量状態とさほど変わらない。その分、電池寿命は短くなるわけだが、自分はeneloopを使っているので、そこは問題ではなかった。

1本だけではバランスがどうなるか気になったが、単4であれば左右どちらでもさほど違いは感じない。自分は右手で使うので親指に近い左側に1本入れた状態にすると、ほとんど違和感はなかった。

[追記]

単4×1(eneloopの750mAhのほぼ新品を満充電状態から)で使っていたところ、5日目で電池切れとなった。さすがにこれは早い。充電池だからまあいいが、乾電池では奨められない方法ではある。

2. スイッチ

裏側にはスイッチ兼用のシャッターがあるが、これが小気味よく動くので、バッテリーの蓋を外して裏返してみると、

くるくる平たく巻いたバネが入っていた。このバネがシャッターのスライドで動く。

バネの一方の端が蓋側のピンに、もう一方がシャッター側のピンに固定され、開閉それぞれの位置で止めるようになっている。もっと安上がりに済ませる方法もあるだろうに、この薄いスペースにこういう細かい機構を組み込んであるのが面白い。

2011/07/16

電気アラート

自作ソフトの紹介です。機能としてはとくに目新しいものではありませんが、シンプルにまとめました。

[追記] 新しい情報はSourceForge.jpのプロジェクトサイトにまとめています。

1. 概要

電力の使用状況データを公開している電力会社(東京電力、東北電力、中部電力、関西電力、九州電力)から一定間隔でデータをダウンロードし、その日のピーク時供給量、最新の使用量を見て、最新の使用率とその動きをタスクトレイから色と数字で知らせます。使用率が高くなっている場合はアラートを出します。

タスクトレイにアイコンが出ます。この数字が使用率で、どれぐらい高いかをこの色で直感的に示します。マウスオーバーすると最新の数字と上下動をチェックできます。

色は以下のカラーチャートに従っています。赤くなってきたら使用率が高くなっています。

アップデートしたときに使用率の閾値を超えている場合は、設定に従って音とバルーンメッセージによるアラートを出します。

アラート音として任意のWAVファイルを再生できます。説明を兼ねてフリーのWAVファイルを同梱していますが、これには、Free音素材「音楽室」(http://www.otosozai.com)のva01.wavを使わせていただいてます。

2. 動作環境

Windows XP、Windows 7で動作します。.NET Framework 4.0がインストールされていることが必要です。

3. ダウンロード

以下からダウンロードできます。
4. その他
  • このソフトはオープンソースです。使用条件については同梱のlicense.txtをご覧ください。

  • Visual Basic 2010 Expressで開発しています。単体で動作するWindowsアプリとしては初なもので、ソースは推して知るべしです。「動けば正義」的な。だからこそ、ソースを公開することにためらいがないということもありますが……。

  • 電力会社が公開しているデータファイル(CSVファイル)は、どこも最初に出した東京電力のものがベースになっているので、共通の部分が多いです。TPTPコネクトでは、ピークタイムを取得するアルゴリズムは全部同じで済んでいます。

    ただ、似たような形式でも意味が微妙に違っていたり、データが更新される速さに差があったりします。東京電力を基準とすると、東北電力は同じぐらい。九州電力は公開を開始したのは一番遅かったですが、かなり頑張っています。関西電力も頑張っていますが、更新が少し遅いです。残る中部電力はまだ1時間ごとのデータしか出していない分、遅れていると言わざるを得ません。
[追記1] 電力会社の更新タイミング

関西電力は3分ごとのデータを公開していますが、更新間隔はこれと少しずれていて、かつ遅れ気味ということを見つけたので、自作ソフトを使ってデータを取得してみました。
関西電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)
UPDATEに
記載された時刻
(日付 時:分)
新しく追加された
データの時刻
(日付 時:分)
更新された
時刻との差
(分:秒)
2011/7/18 3:00:152011/7/18 2:552011/7/18 2:4218:15
2011/7/18 2:4515:15
2011/7/18 3:05:052011/7/18 3:00--
2011/7/18 3:10:072011/7/18 3:052011/7/18 2:4822:07
2011/7/18 2:5119:07
2011/7/18 3:15:072011/7/18 3:102011/7/18 2:5421:07
2011/7/18 2:5718:07
2011/7/18 3:20:042011/7/18 3:152011/7/18 3:0020:04
2011/7/18 3:0317:04
2011/7/18 3:25:082011/7/18 3:202011/7/18 3:0619:08
2011/7/18 3:0916:08
2011/7/18 3:30:142011/7/18 3:252011/7/18 3:1218:14
2011/7/18 3:1515:14
2011/7/18 3:35:062011/7/18 3:30--
2011/7/18 3:40:062011/7/18 3:352011/7/18 3:1822:06
2011/7/18 3:2119:06
2011/7/18 3:45:082011/7/18 3:402011/7/18 3:2421:08
2011/7/18 3:2718:08
2011/7/18 3:50:062011/7/18 3:452011/7/18 3:3020:06
2011/7/18 3:3317:06
2011/7/18 3:55:052011/7/18 3:502011/7/18 3:3619:05
2011/7/18 3:3916:05
2011/7/18 4:00:092011/7/18 3:552011/7/18 3:4218:09
2011/7/18 3:4515:09
2011/7/18 4:05:052011/7/18 4:00--
2011/7/18 4:10:052011/7/18 4:052011/7/18 3:4822:05
2011/7/18 3:5119:05
2011/7/18 4:15:052011/7/18 4:102011/7/18 3:5421:05
2011/7/18 3:5718:05
2011/7/18 4:20:052011/7/18 4:15--
2011/7/18 4:25:052011/7/18 4:202011/7/18 4:0025:05
2011/7/18 4:0322:05
2011/7/18 4:30:142011/7/18 4:252011/7/18 4:0624:14
2011/7/18 4:0921:14
2011/7/18 4:1218:14
2011/7/18 4:1515:14
(注)2秒間隔で更新をチェックし、更新があればデータを記録していく方式。「CSVファイルが更新された時刻」は自作ソフトを実行中のPCのものなので、誤差があり得る(以下同じ)。

見てのとおり更新時刻の間隔は5分で、UPDATEに記載された時刻の5分後になっています。データは3分ごとなので当然ずれていくわけですが、5分の更新で3分×2のデータを追加するのを基本として、詰まってくるとスキップするようです。

ただ、法則性があまりはっきりしないのと、データが細かい割に更新時刻とのタイムラグがおよそ15~24分と、結構あるのがちぐはぐで、謎仕様です。

他の東京電力、東北電力、九州電力はというと、データもUPDATEに記載された時刻、更新時刻も5分ごとなので、ずれることはありません。東京電力の場合は、
東京電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)
5分刻みの
時刻との差
(分:秒)
UPDATEに
記載された時刻
(日付 時:分)
新しく追加された
データの時刻
(日付 時:分)
更新された
時刻との差
(分:秒)
2011/7/18 10:45:550:552011/7/18 10:402011/7/18 10:405:55
2011/7/18 10:51:251:252011/7/18 10:452011/7/18 10:456:25
2011/7/18 10:56:471:472011/7/18 10:502011/7/18 10:506:47
2011/7/18 11:02:132:132011/7/18 10:552011/7/18 10:557:13
2011/7/18 11:08:073:072011/7/18 11:002011/7/18 11:008:07
2011/7/18 11:10:500:502011/7/18 11:052011/7/18 11:055:50

データと更新時刻のタイムラグは5~8分です。

これは東北電力と九州電力と照らし合わせると、データの時刻の表記方法がこれらとは違っていて、5分ずれているかもしれません。例えば10:45のデータは10:40~10:45の5分間ではなく、10:45~10:50の5分間を示すというように。ただ、それにしては早すぎる場合もあるので(差が1桁のときもある)、不明です……。

また、「5分刻みの時刻との差」というのは5分、10分、15分…という5の倍数の時刻との差で、自動アップデートのタイミングを決める参考になります。これは大体2分以内に収まっています。

東北電力の場合は、
東北電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)
5分刻みの
時刻との差
(分:秒)
UPDATEに
記載された時刻
(日付 時:分)
新しく追加された
データの時刻
(日付 時:分)
更新された
時刻との差
(分:秒)
2011/7/18 11:12:142:142011/7/18 11:122011/7/18 11:102:14
2011/7/18 11:17:142:142011/7/18 11:172011/7/18 11:152:14
2011/7/18 11:22:132:132011/7/18 11:222011/7/18 11:202:13
2011/7/18 11:27:152:152011/7/18 11:272011/7/18 11:252:15
2011/7/18 11:32:132:132011/7/18 11:322011/7/18 11:302:13
2011/7/18 11:37:152:152011/7/18 11:372011/7/18 11:352:15

規則正しく2分14秒ごとに更新しています。タイムラグも同じく2分14秒です。とても優秀です。

九州電力の場合は、
九州電力の更新時刻
CSVファイルが
更新された時刻
(日付 時:分:秒)
5分刻みの
時刻との差
(分:秒)
UPDATEに
記載された時刻
(日付 時:分)
新しく追加された
データの時刻
(日付 時:分)
更新された
時刻との差
(分:秒)
2011/7/18 11:38:203:202011/7/18 11:352011/7/18 11:353:20
2011/7/18 11:43:203:202011/7/18 11:402011/7/18 11:403:20
2011/7/18 11:47:202:202011/7/18 11:452011/7/18 11:452:20
2011/7/18 11:53:203:202011/7/18 11:502011/7/18 11:503:20
2011/7/18 11:57:202:202011/7/18 11:552011/7/18 11:552:20
2011/7/18 12:02:192:192011/7/18 12:002011/7/18 12:002:19

こちらも2分20秒か、3分20秒ごとに更新しています。タイムラグも同じ時間で、東北電力に次ぎます。

以上のようなことを考慮に入れて、電気アラートでは、5分刻みの時刻に2分30秒を加えた時刻(7分30秒、12分30秒、17分30秒……)に自動アップデートを行うようにしています(ただし、時間の経過とともに少しずれていきます)。

電力会社ごとに細かく合わせるように変更しました(電気アラート(続)参照)。

[追記2] 日またぎ時の再開時刻

深夜0時に日付が変わった後、電力会社のデータは更新がしばらく途切れます。もちろん、この時間帯に途切れても実用上は何の問題もありませんが……。

とにかく、正常なデータの更新が再開する時刻を同じく自作ソフトで調べてみたのが以下です。
東京電力
(時:分:秒)
東北電力
(時:分:秒)
関西電力
(時:分:秒)
九州電力
(時:分:秒)
2011/7/211:05:531:02:081:19:570:08:14
2011/7/221:07:401:02:171:20:070:08:42
  • 東京電力と東北電力は、その日の1回目の更新で前日のデータを全部出した後、更新が止まり、1時過ぎに0時台の1時間のデータとともに、5分ごとのデータの更新が再開します。これも一つの割り切りだとは思います。

  • 関西電力は、更新は止まらないのですが、中身は前日のデータという状態が続き、中身もその日のデータに切り替わるのは1時20分頃です。止まらないのはいいのですが、あまり行けてない感じがします。

  • 九州電力は、1回だけ更新がスキップしますが、その日の2回目のタイミングから更新が再開します。圧倒的に早いです。まあ九州電力は1時間ごとのデータを出してないので、そこが他とは違いますが。
以上のように、九州電力を除いて、0~1時頃の間は正常なデータがリアルタイムで出ていません(その間のデータは再開した時点でまとめて出ます)。電気アラートでは、正常でないデータはスルーするようにしているので、再開するまで前日のデータが表示されたままになります。実用上は問題ないと思いますが、念のため。

2011/07/01

東京電力の電力状況

いよいよ夏到来の7月ということで、東京電力の地域の電力状況について中間まとめをしてみる。

初めに、使用率という数字はYahoo!などが(たぶん一目で分かるように)東京電力のデータを加工して出しているだけで、東京電力自身が積極的に出しているものではないので、念のため。自分はTPTPコネクトで計算してバッテリ駆動時間の閾値に使っているが。

1. 電力使用率とピークタイム

3/23から6/30までの電力使用率とピークタイムを一覧にしてみた。赤みが強いほど使用率が高い。なお、前回は速報値で計算したが、今回は確定値で計算したので、5/7までの数字でずれている部分がある。
使用率はゴールデンウィーク明けの5/9の週に高くなってからは低い状況が続いてきたが、6/20の週にぐぐっと上がり、週末を挟んでまた上がってきている。

ピークタイムに関しては、東京電力による予想の的中率はあまり高くないが、数字的には僅差だったりすることが多いので、それほど外れているわけでもない。

一方、ピーク使用量も見れば分かるとおり、使用率と使用量は単純な比例関係にはない(使用率の高い日が使用量も高い日とは限らない)。これは母数の「ピーク時供給力」も日ごとに変動しているからで、使用率を理解するにはこの間の関係を見る必要がある。

2. 電力使用量と「ピーク時供給力」

まず3/23から5/11までについて、電力使用量と「ピーク時供給力」、さらに都心部の最高気温(気象庁のデータによる)の推移を見ると、
ピーク使用量が「ピーク時供給力」に近づくほど使用率は高くなるが、3月の切迫した状況を脱した後、4月に入ってからは一部の高い日を除いて余裕がある。

基本的に使用量は平日に高く、週末に低くなるが、東京電力はそうした需要を予想して「ピーク時供給力」を調整しているらしい(発電施設の整備点検のやり繰りがあるだろうし、需要がないのに高くしておく理由もない)ことが見て取れる。

また、使用率が特に高い日を見てみると、
  • 4/4に90%を超えたのは、週初めの需要を甘く見ていた(翌日から供給力を上げたこともあり、使用率は下がっている)
  • 4/23に90%を超えたのは、週末だから需要が下がると予想したら、意外に下がらなかった
  • 4/29と5/6に90%を越えたのは、需要が落ちるゴールデンウィーク直前と狭間だったにもかかわらず、需要がそれほど落ちなかった
からと推測できる。つまり、使用率が高くなったのは、供給力の制約というより、東京電力の予想よりかは需要があったからという方が正しいように思う。どうもこの点を誤解している人が多い気がする。もちろん、その日にスタンバイしている供給力の上限に近づいているという意味では切迫しているわけだが。

続いて5/12から6/30までを見ると、
5/9の週は「ピーク時供給力」が低めだったので使用率が高くなっているが、それ以降は東京電力が供給力を上げたにもかかわらず需要は横這いだったので、使用率は低い状況が続いていた。

その間にも6/6の週、6/13の週と、東京電力は供給力をじわじわ上げて用意してきていて(過去の実績によるものか)、6/20の週に一気に引き上げた。その週の半ばに気温の上昇とともに使用量が大きく伸び、久しぶりに90%を超えたわけだが、それを予想して東京電力は待ち構えていたことが分かる。

その後、東京電力は週末を挟んでさらに供給力を引き上げて対応している。

3. 今後

7月1日の東京電力のプレスリリース(今夏の需給見通しと対策について(第4報))によれば、この夏は大体5500万kWが供給力の上限となるらしい。既に「ピーク時供給力」は5000万kWを超え、これまでは余裕のあった東京電力も、いよいよ本気を出さないといけなくなりつつある。これまでは使用率といっても、それ自体に深い意味はなかったが、今後は本当に供給力との戦いの意味を持つようになってくるのだろう。

一方、6/29は都心部の最高気温が35度に達する中で、使用量は(7月からの電力使用制限が始まる前にして)4570万kWに留まっている。この気温と使用量の関係について、早野東大教授は「(参考出品)TEPCO最大電力と東京の最高気温の関係」で、これまでの実績では最高気温1度上昇につき使用量が約135±17万kWの上昇になっていることを示している。

今後もこの相関関係が続くなら、最高気温が40度に達しても使用量は5300万kWぐらいに留まる計算になるので、このまま波乱がなければ凌げそうにも思う。ただ、さすがに気温が30度台後半になると、我慢とか工夫とかで何とかなる世界ではなくなるのでクーラーを使う人が増えるかもしれず、使用量が急上昇するかもしれない。

いずれにしても、今年の夏は「忘れらない夏」になりそうではある。