8th way to explore the world

ThinkVantageボタン

noreply@blogger.com (EMO) — Thu, 01 Dec 2011 00:02:00 +0000

ThinkPadのThinkVantageボタンは、現在はThinkVantage Toolboxの起動ボタンになっているが、これを他のプログラムの起動に利用する方法について。

この話は既にThinkVantageボタンに出ていて、ThinkVantage Toolboxをインストールした状態でレジストリがどうなっているかを確認すると、以下のようになっていた。

これを見れば方法は簡単で、以下のようにすればいい。

HKEY_LOCAL_MACHINE\SOFTWARE\IBM\TPHOTKEYの直下に「8001」という名前のキーを作成する。
その直下に「File」という名前の文字列値を作成する。
この値のデータに起動するプログラムのパスを入れる。

ただ、試したところ、プログラムは起動できるがアクティブにはならず（最前面に来ない）、他のプログラムをデスクトップに広げていると前面に出すのに一手間かかるという問題があった。まあランチャー的なプログラムを挟めば解決できると思うが。

海関係

noreply@blogger.com (EMO) — Wed, 30 Nov 2011 04:35:00 +0000

市ヶ谷の防衛技術シンポジウム2011に寄ったときに、海関係でとくに興味深かったもの。

1. 音響レンズ

従来のソナーでは、目標物の形状を把握するには音響ビームで走査してその結果を合成する必要があったが、音を光のように屈折させる音響レンズを使って水中の物体を一度に「見る」ことを可能にするもの。

（研究開発セッションの発表資料「R1-2 水中画像化ソーナー用音響レンズについて」より）

水中で物体をどう把握するかということを考えるときに革新的な技術だと思う。もっとも、現状は音響レンズ設計のためにアクリルとゴムを素材にしたときのシミュレーション手法を研究中という段階だが。

2. ひゅうが

『ひゅうが』型の設計について、さらっと説明があった。既に情報は結構出ているので新味は薄かったが、興味を惹かれたのは吸排気路。

（研究開発セッションの発表資料「R2-2 進化を遂げたDDH、ひゅうが」より）

『ひゅうが』は推進用に4基、発電用に4基の計8基のガスタービンエンジンを持っているが、この吸気路（吸気口の位置が高いのは傾斜時に浸水しないようにするため）と排気路（水平部分が楕円形になっているのは高さを抑えるため）にかなりのスペースを取られているのが分かる。もっと格納庫を広く取れないのかなと思ったりもしたが、こういう事情もあると。

ちなみに、吸気路の水平部分が一層低いのは、エレベーターのある部分だからと思う。以下は後部エレベーターが上昇した跡の様子（8月の一般公開時のもの）。

エレベーターが下降時に嵌まるスペースと、その下にエレベーターが上昇時に上昇させて格納庫を面一にするための床があって、これらが高さを取っている。

また、ギャラリー甲板が結構厚く見えるが、エレベーターの開口部（同上）を見てもこんなものか。

3. DDR

21年度に引き続き、22年度に試設計されたDDR（後ろは21年度のDDR）。

レーダーは前部の統合アンテナに集め、その分煙突は低くし、上構中央部を壁で囲んでいる。全体的に21年度よりすっきりまとまっている。そのためもあってか、昨年の5,400トンから5,100トンに少し小型化。

4. おまけ

22DDHは昨年と外観は変わらないが、説明が少し変わった。

昨年と違うのは、

対空レーダーがOPS-50から「OPS-50級」に変更
対水上レーダーとして「OPS-28F級」を搭載（この画面には出てない）
戦闘指揮システムとして「OYQ-12」を搭載（『いせ』はOYQ-11）
電子戦装置として「NOLQ-3D-1」を搭載（『ひゅうが』はNOLQ-3C）
ソナーが昨年のOQQ-22から「OQQ-23級」に変更（『いせ』はOQQ-22）

それぞれ従来よりアップグレードしたものが搭載される（予定）ということで、順当なところ。

DiskMarkStream alpha

noreply@blogger.com (EMO) — Sun, 30 Oct 2011 15:42:00 +0000

ふと思い付いて、hiyohiyoさん作のCrystalDiskMark（3.0.1）を自動実行するマクロツールである、DiskMarkStreamを作りました。

CrystalDiskMarkで計測する場合、様々な条件でのテストを（確認の意味を含めて）行うことがありますが、そういうときにとくに役に立ちます。マクロファイルで一遍に設定しておいて、計測を開始した後は放置、というのが基本的な使い方です。

新しいデバイスを買ってきたときに、まず速度を計っておこう……ついでに環境も少し変わってるから前のデバイスも一緒に計っておくか……とやっていると、ついつい睡眠不足になったりしますが、それが楽になります。
SSDの場合、計測前にどういう状態だったかの影響が結構あり、計測に難しさがありますが（CrystalDiskMarkも3.0でその点が考慮されています）、各テストの前に任意の休み時間を挟むなどのパターンを組むことができます。

使う人の工夫次第で色々便利に使えるのではないかと思います。試してみて何か気づいた点などあれば、ぜひ報告をお願いします。

プロジェクトサイト: DiskMarkStream 英語 / 日本語 at SourceForge.net
実行ファイル from SourceForge.net

[追記]

CrystalDiskMarkのページで紹介いただきました。ありがとうございます。

画像ガジェット

noreply@blogger.com (EMO) — Fri, 07 Oct 2011 19:08:00 +0000

Microsoft公式のサイドバーガジェット（デスクトップガジェット）のダウンロードサイトであるWindows Live Galleryが終了したのに伴い、ガジェットの多くがダウンロードできなくなりましたが、その中で自分が愛用してきた『画像』について、作者の中山智仁さんの許可が得られたので、オリジナル版の再頒布および表示サイズを調整できるようにした改造版の頒布をすることにしました。

（改造版では、原画像に対する比率を10-100%の範囲で直接指定することが可能）

プロジェクトサイト: Picture-gadget at SourceForge.JP
ガジェットファイル（オリジナル版と改造版の同梱）from SourceForge.JP

自分の使ってきたソフトウェアがいきなり入手不能になるというのは（保存してあればいいとしても）うれしくはないもので、再頒布を快く許可してくださった中山さんに感謝します。

[修正]

改造版がWindowsの地域の形式によって正常に機能しない問題を修正。

Windows To GoなUSBメモリ

noreply@blogger.com (EMO) — Fri, 23 Sep 2011 08:23:00 +0000

Windows 8 pre-betaであるところのWindows Developer Preview（以下、略してWDP）には、完全に独立したOSをUSBメモリから起動できるWindows To Goがある。これがあればPCにインストールしたままにしなくてもWDPが使えるので、このUSBメモリを作成してみた。

1. 作成方法

BUILD2011の資料を見ると、作成方法がさらっと書いてある。

（Channel9 BUILD2011 Running Windows from an external USB drive with Windows To Goのスライド資料より）

環境依存のドライブレターがそのまま入っているので分かりにくいが、大体以下の手順で作成できることが分かる。

imagex.exeで（予め作成しておいた）OS環境のイメージファイル（.wim）をUSBメモリに展開する。
Bcdboot.exeでOSを起動可能にする。

ただ、これを試すには幾つか問題があって、

imagex.exeか他の方法でイメージファイルを作成するときに必要なオプション、その有無が不明。
WDPのバージョン（Build 8102）に対応したimagex.exeはWindows ADK（Windows 7までのWindows AIKに相当）に入っているようだが、これをダウンロードするにはMSDNサブスクリプションが必要。

何とかできなくもなさそうだが骨が折れそうなので二の足を踏んでいたところ、先人によれば（How to Create a Windows To Go USB Drive）割と簡単にできるらしい。すなわち、imagex.exeはWindows 7のWindows AIKにあるもので可で、イメージファイルはWDPのインストールDVD中のものを使えばいいらしい。

これに従えば、手順は以下のようになる。

Windows 7のWindows AIKをインストールし、imagex.exe（64bitは\Program Files\Windows AIK\Tools\amd64に、32bitは\Program Files\Windows AIK\Tools\x86にある）を適当な場所にコピーしておく。
32GB以上のUSBメモリをDiskPartでブート可能にしておく。詳しい方法は従来と同じ（diskpartを使ってWindows Vista/7のインストールUSBメモリを作る）。ただし、ファイルシステムはNTFSで。
WDPのインストールDVDのISOファイルをマウントして（Windows 8では標準でこれが可能）、install.wim（\sourcesにある）をimagex.exeと同じ場所にコピーしておく。
USBメモリを挿し、管理者としてコマンドプロンプトを開いて、imagex.exeのある場所から以下を実行（かなり時間がかかる）。ここまではWindows 7でも可。

imagex.exe /apply install.wim 1 d:\
（USBメモリのドライブレターがD:の場合）
続いて以下を実行。ここはWDPでなければ不可（Windows 7ではBcdboot.exeに/fオプションがないので）。

bcdboot.exe d:\windows /s d: /f ALL
（同上）

なお、このイメージファイル（install.wim）はインストール途中の状態を保存したものなので、これでブートすると残りのインストールが行われた後に起動する。

2. 実際（以下、大幅に再構成）

実際に試した条件は以下のとおり。

PC: ThinkPad X61s（CPU: Core2Duo 1.8GHz、メモリ: 4GB、USB2.0）
ISOファイル: 開発ツール付きの64bit版（WindowsDeveloperPreview-64bit-English-Developer.iso）
USBストレージ:
- Buffalo RUF3-S32GS-BK (32GB、USB3.0、ファームウェアアップデート済み、TurboPCなど付属ツールは使用しない)
- GreenHouse GH-UFD3-32GF (32GB、USB3.0)
- Mtron MSD6000（MSD-SATA6025-032-N-A、32GB、SATAのSSD）
  ＋SilverStone SST-TS02B（USB2.0、2.5インチ用のUSBケース）

このPCではUSB3.0のUSBメモリも必然的にUSB2.0接続になる。Windows To GoはUSB3.0推奨らしいので力不足ではあるが、WDPを内蔵SSD（X25-M G2 80GB）にインストールした状態ではさくさく普通に動作する。

先に、それぞれの速度をCrystalDiskMarkで確認しておく。なお、X61sはストレージ速度が遅いPCなので（前世代のX60sと比べても遅い）、他のPCならもっと速いと思われる。

まずRUF3-S32GS-BK。

テストサイズが1000MBのときの4Kランダムライトが極端に遅いのが分かる。

次にGH-UFD3-32GF。

これは1000MBでも4Kランダムライトがそれなりの値を維持している。なお、他の人のベンチマーク結果を見ると、このUSBメモリの値はこれよりかなり高い。

さらに比較用として、手持ちのUSB2.0のUSBメモリの中で最速のPicoBoost 8GB（以前の計測結果）。

1000MBでもそれほど遅くなっていない。これに比べるとRUF3-S32GS-BKの4Kランダムライトの遅さが際立つ。

最後にMSD6000によるUSB SSD。このMSD6000は最初期のSSDで、引退させていたのを探し出してきた。

当然といえば当然だが、ランダムライトはUSBメモリとは段違いに速い。

RUF3-S32GS-BKの場合

まず用意したのがRUF3-S32GS-BKで、これが順調に行っていればそこで終わりだったのだが。

作成は手順どおりにできたが、imagex.exeの実行には209分もかかった。

作成したUSBメモリからブートすると、インストールに長い時間がかかった後、WDPが起動した。起動後は、見た目は内蔵SSDから起動したときと変わらない。ページファイルを無効にした状態でUSBメモリの使用容量は約14GB。

（C:がWindows To GoのUSBメモリ）

ただし……起動と終了を何度か繰り返すうちにはっきりしたが、動作が極めて、極めて遅い。

起動時間（電源ボタンを押してからStart画面が出るまで）を内蔵SSDと比べると、

内蔵SSD: 18秒
RUF3-S32GS-BKによるWindows To Go（初回ではない）: 8分25秒

起動時だけならまだしも、起動後も何か操作する度にしばらく待たされる。上のスクリーンショットも、このために起動し、デスクトップを開き、エクスプローラを開き、スクリーンをコピーし、ペイントに貼り付け、それを保存し、終了するまでに30分近くかかっている。とても実用にはならない。

GH-UFD3-32GFの場合

ここは実際の順番とは前後する。

Windows To Goが極めて遅いのはRUF3-S32GS-BKのランダムライトの遅さが原因という可能性があるので、改めてBUILD2011で配布されたUSBメモリを見ると、外観からKingstonのData Traveler Ultimate 3.0シリーズということが分かった。

このシリーズには第1世代（G1）と第2世代（G2）とがあって、G2の方がシーケンシャルリードでは速くなっているが、ランダムライトではG1の方が他のUSBメモリの中でも飛び抜けた速さを誇っている。これはG1が中身的にはUSB SSDに近いということがあると思う。

[参考]
AnandTech: Kingston DataTraveler Ultimate 3.0 & OCZ Enyo, Quick Look at Two USB 3.0 SSDs
DecryptedTech: Kingstons' Data Traveler Ultimate G2 hits 100+MB/s

Microsoftが配布したのがG1かG2かは分からないが、ランダムライトの速さからいえばG1の方が理想的ではある。が、生産終了品でうまく入手できなかったのと、G2もランダムライトは速い方なので、G2とほぼ同じコントローラを持ち、入手性も高いGH-UFD3-32GFに方向転換した次第。

GH-UFD3-32GFでWindows To Goを作成したところ、imagex.exeの所要時間は50分と、かなり短縮された。

作成したUSBメモリからブートしてのインストールもそれほど待たされることなく、WDPが起動した。動作は内蔵SSDに比べればややぎこちないが、普通に操作できる。起動時間も十分に許容範囲。

内蔵SSD: 18秒
GH-UFD3-32GFによるWindows To Go: 46秒

が……なぜかIEがインターネットに接続できない（10秒ぐらいで自動終了する）。Firefoxでは接続できるので、OSは繋がっているのだが。IEだけでなく、IEの機能を内部的に利用しているであろう標準アプリ（Metroアプリを含めて）も接続不可。Windows Updateもかけられないので、打つ手なし。原因は不明だが、これも実質的に使えない。

なお、RUF3-S32GS-BKでは遅すぎてこの問題を確認するには至らなかった。

MSD6000（USB SSD）の場合

RUF3-S32GS-BKでは遅すぎて使い物にならないと判明した後、USB接続のストレージでランダムライトが速く、手持ちで試せるものとして浮かんだのがMSD6000をUSB接続にすること。

このUSB SSDでWindows To Goを作成すると、まずimagex.exeの所要時間が段違い。20分で終了した。

このUSB SSDからブートするとインストールもさくっと進み、WDPが起動。操作した感じも内蔵SSDと変わらない。起動時間もリーズナブル。

内蔵SSD: 18秒
MSD6000によるWindows To Go: 32秒

ページファイルを無効にした状態でUSB SSDの使用容量は約14GBで、これは変わらない。種類はHDDになる。

（C:がWindows To GoのUSB SSD）

エクスペリエンスインデックスはこんなもの（上が内蔵SSD、下がUSB SSD）。

Primary hard diskは、内蔵SSDの7.2に対してUSB SSDは5.2なので、そんなに低くはない。

以上、USB SSDで作成したらさくさく動作するWindows To Goができた。

3. まとめ

Windows To Goの動作には、USBメモリのランダムライトの速度が重要。これはOSがその上で動作することを考えれば当然ではある。接続がUSB2.0かUSB3.0かは直接関係ないし、PCの性能もあまり関係ないが、USBメモリの速度はPC本体にかなり左右されるところがあるので、無関係とも言えない。

これはReadyBoostの条件と似ているが、最近の、とくに32GB超のUSBメモリではReadyBoost対応は重視されてないようなので、盲点ではある。高速なシーケンシャルアクセスを謳う製品でも、ランダムライトが遅ければWindows To Goには不適格。この点は、Windows 8がリリースされるときにはReadyBoostのような基準を作る必要があると思う。

とりあえず容量と速度を考えれば自分のようにSSDを再利用するのが手っ取り早いが、ランダムライトが遅くないUSBメモリを慎重に選ぶか、先々は、教えていただいたSuper TalentのUSB 3.0 Express RC8のような中身的にUSB SSDに近いものを使うのがいいと思う。ただし、IEの問題は残るかもしれない。

4. 注意点

Windows To Goの場合に限らないが、WDPの起動時に自動chkdskがかかった後、Windows 7で作成したパーティション（ファイルシステムはNTFS）がアクセス不能になったことが複数回あった。逆に、Windows 7で自動chkdskがかかった後、WDPのシステムパーティションがアクセス不能になったこともあった。

バックアップしておけばいいことだが、一応注意を要する。

[追記1]

Windows To Goの作成例。

Internet Watch: 清水理史のイニシャルB: 第460回：Windows Developer Preview登場！ USBで携帯するWindows 8「Windows To Go」を試す
ComputerWorld: Windows Developer Preview、Windows To Go とゴー
人生無限ループ: Windows8(仮)『Windows To Go』を試す（その１）
Windows8(仮)『Windows To Go』を試す（その２）

並みのUSBメモリでは使い物にならないという点で一致。清水さんが「実用は厳しい」と評しているUSBメモリと、ぱすわさんが「一応使えるレベル」としたGreen HouseのPicoDrive Dual Xの速度は同程度のように見えるので、その辺が境界線になるのだろうと思う。

また、ぱすわさんの場合もIEが起動できないということなので、これは普遍的な問題らしい。

さらに、清水さんの記事を読んで、改めてBUILD2011での動画を見ると、デモで使われていたのはSuper TalentのRAIDDrive USB3.0だった模様（市場で入手できる現在最速の、8chでSuper Talentのドライブと言っている）。確かにこれなら速度的には別格だから、道理でという感じ。資料を見直しても「USB Drive」と書いていても「USB Stick」とは書いてないので、これを（並みの）USBメモリと捉えたのが、ある意味ミスリーディングだったようにも思う。

[追記2]

USB SSDでWindows To Goを使っていたところ、サスペンド、ハイバネーションともできないことが判明した。内蔵SSDから起動した場合には可能なので、Windows To Goの場合特有の問題だと思う。

なお、内蔵SSDから起動した場合も「Power」に「Sleep」の選択肢は出ないが、ThinkPad式のショートカットキー（Fn + F12）でハイバネーションに入り、電源キーでレジュームする。ただし、サスペンド（Fn ＋ F4）したときもハイバネーションに入る模様（非常に速いので実害はないが）。

NAS Herder beta

noreply@blogger.com (EMO) — Sat, 03 Sep 2011 01:59:00 +0000

Beta版ということで公開しました。外見的な変化はFan回転数の横にグラフを付けたぐらいです。

プロジェクトサイト: NAS Herder 英語 at SourceForge.net
実行ファイル from SourceForge.net

関連スレッド: Beta Tester Wanted (new Windows app for ReadyNAS)

[更新]

ボリューム使用率とUPS充電率のバー表示を変更しました。ボリューム使用率が90%を超えると赤に変わります。このvisual styleで色を自由に変えられるプログレスバーのサンプルコード。

標準のプログレスバーをこれに使っていたところ、Windows Developer Previewでは自動的にマーキーになってしまってましたが（本来のプログレスバーとしては間違ってはいない）、自分で作成したことで解決となりました。

NAS Herder 開発中

noreply@blogger.com (EMO) — Tue, 23 Aug 2011 23:46:00 +0000

ReadyNAS用のWindowsアプリとしてNAS Herder（仮）を開発中です。

見て想像できるとおり、ReadyNASの起動・監視・終了をタスクトレイから行えるソフトです。監視にはNetGear純正のRAIDarと同じプロトコルを利用することができます（追記2にサンプルコードあり）。

起動・終了には基本的にこれ（遠隔から電源オン/オフ）と同じことをしていますが、この機能とWindowsの起動・終了・サスペンド・レジュームを絡めて電源同期ができるのが特徴かなと。

大体完成していますが、電源同期関係はまだテストが必要という状態です。VB.NETで開発するのも3本目なので、慣れてはきましたが、通信機能を4種類実装したり、それをマルチスレッド化したりで、内情的には色々あって……。前と違って季節ものではないので、急いではないのですが。

想定している使用環境は日本に限らないので、全部英語です。多言語化も難しくはないのですが、正直そこにあまり手間をかけたくないということもあり。まあ需要次第ということで。

[追記1] 参考

必ずしも直接参考にしたわけではないですが、先人への敬意を込めて。

ReadyNAS HDD temperature by nullnullx (Andrey Mischenko)

Perlのスクリプト。RAIDarプロトコルを利用するソフトとしては祖に当たるもの。自分はPerlは使えませんが、やっていることは何となく分かります。開発は名前から判断すると、たぶんロシアの人。関連スレッド（Disk drive temperatures）
RAIDar.NET by Pasadena (Rüdiger Fresemann)

VB.NETによるWindowsアプリ。RAIDarのプロトコルの結果をガジェット的に表示するもの。自分の環境ではなぜかReadyNASからの返信を受け取れません。報告しなければ。開発はドイツの人。関連スレッド（Developing Monitoring tools for ReadyNAS NV+）。
ReadyNas Monitor by DotBlog (Olivier Dahan)

おそらくC#によるWindowsアプリ。ビジュアルに凝ってますが、自分の環境ではなぜかエラーが出ます。報告しなければ。開発はフランスの人。関連スレッド（Wanted : Beta tester for a ReadyNas Monitor）。
Netgear ReadyNAS Duo command line shut down utility by Shawson

ReadyNASを終了させるWindowsアプリ。Curlを使う方法は既に紹介されてましたが、C#によるもの。WebClientを使ったサンプルコードあり（Automatic NAS Box shutdown – How to POST the shutdown command over SSL with HTTP authentication from a dot net Console app (Part 1/2)）。開発はイギリスの人。関連スレッド（Command Line Shutdown for ReadyNAS PRO PIONEER Edition）。

自分はHttpWebRequestを使っていて、それで作成した後に知りましたが、SecurityProtocolType.Ssl3を指定する部分は取り入れさせてもらいました。

[追記2] RAIDarプロトコルのサンプルコード

移動しました（RAIDar Protocol Sample）。

[追記3]

関連スレッド: ReadyNAS Remote Monitoring Tool?

[追記4]

Beta版を公開しました。

電気アラート（続）

noreply@blogger.com (EMO) — Tue, 02 Aug 2011 14:13:00 +0000

電気アラートに関する続きです。

電力会社（東京電力、東北電力、関西電力、九州電力）は5分ごとの使用量データを5分に1回更新していますが、タイムラグを短くしようとすると、この更新をどう追いかけるかが問題になります。

単純に力技でいいなら、より短い間隔でアクセスし続ければ更新を引っ掛けやすくなるわけですが、それはあまりうまくないと思うので、アクセスも5分に1回とすると、そのタイミングが重要になります。

1. 電力会社の更新タイミング

ということで、電気アラートの動作検証と平行して、また自作ソフトで電力会社の更新タイミングを調べた結果が以下です。7/28～8/2の5日間、3秒間隔で更新をチェックしたものですが、ソフトの開発で中断していた時間も長いので、網羅的なものではありません（更新回数は1000回強）。

見てのとおり、東北電力と関西電力は鋭い山が1つだけで、更新タイミングはほぼ固定されています。

九州電力は3つの山ができていて、3つのタイミングがあることが分かります。ただ、どの順番でどのタイミングになるかという法則性は、元の更新時刻を見てもよく分かりませんでした。

で、東京電力は前半に低い山並みができてますが、これには理由があります。例として、7/31の19:00～21:00の更新時刻を挙げます。

東京電力の更新時刻（7/31 19:00～21:00）
CSVファイルが更新された時刻 (日付時:分:秒)	5分刻みの時刻との差 (秒)	UPDATEに記載された時刻 (日付時:分)	新しく追加されたデータの時刻 (日付時:分)
2011/7/31 19:01:00	60	2011/7/31 18:55	2011/7/31,18:55
2011/7/31 19:06:35	95	2011/7/31 19:00	2011/7/31,19:00
2011/7/31 19:12:06	126	2011/7/31 19:05	2011/7/31,19:05
2011/7/31 19:17:01	121	2011/7/31 19:10	2011/7/31,19:10
2011/7/31 19:22:20	140	2011/7/31 19:15	2011/7/31,19:15
2011/7/31 19:25:21	21	2011/7/31 19:20	2011/7/31,19:20
2011/7/31 19:30:37	37	2011/7/31 19:25	2011/7/31,19:25
2011/7/31 19:36:26	86	2011/7/31 19:30	2011/7/31,19:30
2011/7/31 19:41:36	96	2011/7/31 19:35	2011/7/31,19:35
2011/7/31 19:47:13	133	2011/7/31 19:40	2011/7/31,19:40
2011/7/31 19:52:30	150	2011/7/31 19:45	2011/7/31,19:45
2011/7/31 19:55:18	18	2011/7/31 19:50	2011/7/31,19:45
2011/7/31 20:00:40	40	2011/7/31 19:55	2011/7/31,19:55
2011/7/31 20:06:05	65	2011/7/31 20:00	2011/7/31,20:00
2011/7/31 20:11:37	97	2011/7/31 20:05	2011/7/31,20:05
2011/7/31 20:17:05	125	2011/7/31 20:10	2011/7/31,20:10
2011/7/31 20:22:30	150	2011/7/31 20:15	2011/7/31,20:15
2011/7/31 20:25:19	19	2011/7/31 20:20	2011/7/31,20:20
2011/7/31 20:30:32	32	2011/7/31 20:25	2011/7/31,20:25
2011/7/31 20:36:18	78	2011/7/31 20:30	2011/7/31,20:30
2011/7/31 20:41:37	97	2011/7/31 20:35	2011/7/31,20:35
2011/7/31 20:46:53	113	2011/7/31 20:40	2011/7/31,20:40
2011/7/31 20:52:21	141	2011/7/31 20:45	2011/7/31,20:45
2011/7/31 20:55:13	13	2011/7/31 20:50	2011/7/31,20:50

更新タイミングは早い時刻から始まって、1回の更新ごとに20～30秒遅れていき、これを5～6回繰り返した後に元に戻るというパターンになっています。かつ、それぞればらつきが大きいので、集計してみると低い山の連続になるというわけです。

また、東北電力、関西電力、九州電力のそれぞれの山の中に谷がありますが、これも理由があって、大まかに休日と平日の差によるものです。

以下は電気アラートのコマンドラインオプションを使って「内部時刻」と「更新状況」を表示させたものです。この「更新状況」は上で使ったソフトのサブセットで、30分間、3秒間隔で更新をチェックします。

これは7/31のものですが、更新タイミング（表中の「差」の列）は大体124秒です。これが8/2になると、

更新タイミングは大体140秒になります。つまり平日は休日より遅くなるわけで、同じ傾向は関西電力、九州電力にも見られ、平日は10～20秒遅くなります。

2. 電気アラートでの対応

以上を考慮して、電気アラートではアップデートのためにアクセスするタイミングを、電力会社ごとのプリセット値として持っています（Ver.0.8.0）。

東北電力の例では、上の7/31の時点では140秒＝2分20秒としていて、これは「内部時刻」の「アップデート」の「次回」時刻に反映されています。が、平日は遅くなることが分かったので、下の8/2の時点では150秒＝2分30秒に変更しています。

この場合、23:07:17に更新されたデータを23:07:30にアクセスして見に行こうとしている直前で、データの時刻から電気アラートに反映されるまでのタイムラグは2分30秒ということになります。まあ、これほどタイムラグを短くできるのは、データが出てくるのが速く、更新タイミングが安定している東北電力ならではですが。

一方、この更新タイミングがずっと同じかは不明なので、タイムラグがどうも長い……というときは、「更新状況」で更新タイミングを確かめた上で（その間のアクセスが増えるのは目を瞑ってもらうとして）、コマンドラインオプションでアップデートのタイミングを指定することで調整できます。

Intel SSDのE2/E3/E4

noreply@blogger.com (EMO) — Tue, 19 Jul 2011 03:00:00 +0000

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シリーズの追補を読んでもらうということで。

マウス三台

noreply@blogger.com (EMO) — Sun, 17 Jul 2011 08:31:00 +0000

クリックボタンがおかしくなった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)
M905	84	99	114	111	136
VX-Nano	73	-	95	-	-
V550 Nano	69	-	97	-	117
M555b	68	-	96	-	116

（注）単4はアダプターを含む（VX-Nanoを除く）。計測したときの電池のブランドが違うので、電池の重量にズレがある。

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

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

[追記]

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

2. スイッチ

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

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

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

電気アラート

noreply@blogger.com (EMO) — Sat, 16 Jul 2011 07:12:00 +0000

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

1. 概要

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

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

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

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

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

2. 動作環境

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

3. ダウンロード

以下からダウンロードできます。

4. 履歴

Ver.0.7.0
初リリース。
Ver.0.7.1
より常駐アプリらしく、ウィンドウが非表示の状態で終了すると（OSの終了時の場合、タスクトレイのアイコンのメニューから終了した場合）、次回起動時にもウィンドウは非表示になるよう変更。
Ver.0.7.2
アラート間隔がずれていくことがある問題を修正。
Ver.0.7.3
日またぎ時で電力会社のデータがおかしくなっているときに（追記2参照）エラーが出ることがある問題などを修正。自動アップデートを常に5分刻みの時刻に2分30秒を加えた時刻に行うよう変更（追記1参照）。複数起動を可能にするよう変更。
Ver.0.8.0
設定の自動アップデート間隔とアラート間隔を見直し。表示に前回からの上下動を加え、タスクトレイアイコンをマウスオーバーしたときのツールチップとバルーンメッセージの形式を見直し。アップデートのタイミングを電力会社ごとに合わせるように変更（電気アラート（続）参照）。コマンドラインオプションに対応し、細かいカスタマイズができるようにした。
Ver.0.8.1
使用率の計算を常に切り上げにしていたが、普通の感覚とずれていたので（ほんのわずかでも上回ると切り上げられる）、四捨五入に変更。
Ver.1.0.0
内部的に細かく修正。一応の完成版。

5. その他

このソフトはオープンソースです。使用条件については同梱のlicense.txtをご覧ください。
Visual Basic 2010 Expressで開発しています。単体で動作するWindowsアプリとしては初なもので、ソースは推して知るべしです。「動けば正義」的な。だからこそ、ソースを公開することにためらいがないということもありますが……。
電力会社が公開しているデータファイル（CSVファイル）は、どこも最初に出した東京電力のものがベースになっているので、共通の部分が多いです。TPTPコネクトでは、ピークタイムを取得するアルゴリズムは全部同じで済んでいます。

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

[追記1] 電力会社の更新タイミング

関西電力は3分ごとのデータを公開していますが、更新間隔はこれと少しずれていて、かつ遅れ気味ということを見つけたので、自作ソフトを使ってデータを取得してみました。

関西電力の更新時刻
CSVファイルが更新された時刻 (日付時:分:秒)	UPDATEに記載された時刻 (日付時:分)	新しく追加されたデータの時刻 (日付時:分)	更新された時刻との差 (分:秒)
2011/7/18 3:00:15	2011/7/18 2:55	2011/7/18 2:42	18:15
2011/7/18 3:00:15	2011/7/18 2:55	2011/7/18 2:45	15:15
2011/7/18 3:05:05	2011/7/18 3:00	-	-
2011/7/18 3:10:07	2011/7/18 3:05	2011/7/18 2:48	22:07
2011/7/18 3:10:07	2011/7/18 3:05	2011/7/18 2:51	19:07
2011/7/18 3:15:07	2011/7/18 3:10	2011/7/18 2:54	21:07
2011/7/18 3:15:07	2011/7/18 3:10	2011/7/18 2:57	18:07
2011/7/18 3:20:04	2011/7/18 3:15	2011/7/18 3:00	20:04
2011/7/18 3:20:04	2011/7/18 3:15	2011/7/18 3:03	17:04
2011/7/18 3:25:08	2011/7/18 3:20	2011/7/18 3:06	19:08
2011/7/18 3:25:08	2011/7/18 3:20	2011/7/18 3:09	16:08
2011/7/18 3:30:14	2011/7/18 3:25	2011/7/18 3:12	18:14
2011/7/18 3:30:14	2011/7/18 3:25	2011/7/18 3:15	15:14
2011/7/18 3:35:06	2011/7/18 3:30	-	-
2011/7/18 3:40:06	2011/7/18 3:35	2011/7/18 3:18	22:06
2011/7/18 3:40:06	2011/7/18 3:35	2011/7/18 3:21	19:06
2011/7/18 3:45:08	2011/7/18 3:40	2011/7/18 3:24	21:08
2011/7/18 3:45:08	2011/7/18 3:40	2011/7/18 3:27	18:08
2011/7/18 3:50:06	2011/7/18 3:45	2011/7/18 3:30	20:06
2011/7/18 3:50:06	2011/7/18 3:45	2011/7/18 3:33	17:06
2011/7/18 3:55:05	2011/7/18 3:50	2011/7/18 3:36	19:05
2011/7/18 3:55:05	2011/7/18 3:50	2011/7/18 3:39	16:05
2011/7/18 4:00:09	2011/7/18 3:55	2011/7/18 3:42	18:09
2011/7/18 4:00:09	2011/7/18 3:55	2011/7/18 3:45	15:09
2011/7/18 4:05:05	2011/7/18 4:00	-	-
2011/7/18 4:10:05	2011/7/18 4:05	2011/7/18 3:48	22:05
2011/7/18 4:10:05	2011/7/18 4:05	2011/7/18 3:51	19:05
2011/7/18 4:15:05	2011/7/18 4:10	2011/7/18 3:54	21:05
2011/7/18 4:15:05	2011/7/18 4:10	2011/7/18 3:57	18:05
2011/7/18 4:20:05	2011/7/18 4:15	-	-
2011/7/18 4:25:05	2011/7/18 4:20	2011/7/18 4:00	25:05
2011/7/18 4:25:05	2011/7/18 4:20	2011/7/18 4:03	22:05
2011/7/18 4:30:14	2011/7/18 4:25	2011/7/18 4:06	24:14
		2011/7/18 4:09	21:14
		2011/7/18 4:12	18:14
		2011/7/18 4:15	15:14

（注）2秒間隔で更新をチェックし、更新があればデータを記録していく方式。「CSVファイルが更新された時刻」は自作ソフトを実行中のPCのものなので、誤差があり得る（以下同じ）。

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

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

他の東京電力、東北電力、九州電力はというと、データもUPDATEに記載された時刻、更新時刻も5分ごとなので、ずれることはありません。東京電力の場合は、

東京電力の更新時刻
CSVファイルが更新された時刻 (日付時:分:秒)	5分刻みの時刻との差 (分:秒)	UPDATEに記載された時刻 (日付時:分)	新しく追加されたデータの時刻 (日付時:分)	更新された時刻との差 (分:秒)
2011/7/18 10:45:55	0:55	2011/7/18 10:40	2011/7/18 10:40	5:55
2011/7/18 10:51:25	1:25	2011/7/18 10:45	2011/7/18 10:45	6:25
2011/7/18 10:56:47	1:47	2011/7/18 10:50	2011/7/18 10:50	6:47
2011/7/18 11:02:13	2:13	2011/7/18 10:55	2011/7/18 10:55	7:13
2011/7/18 11:08:07	3:07	2011/7/18 11:00	2011/7/18 11:00	8:07
2011/7/18 11:10:50	0:50	2011/7/18 11:05	2011/7/18 11:05	5: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:14	2:14	2011/7/18 11:12	2011/7/18 11:10	2:14
2011/7/18 11:17:14	2:14	2011/7/18 11:17	2011/7/18 11:15	2:14
2011/7/18 11:22:13	2:13	2011/7/18 11:22	2011/7/18 11:20	2:13
2011/7/18 11:27:15	2:15	2011/7/18 11:27	2011/7/18 11:25	2:15
2011/7/18 11:32:13	2:13	2011/7/18 11:32	2011/7/18 11:30	2:13
2011/7/18 11:37:15	2:15	2011/7/18 11:37	2011/7/18 11:35	2:15

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

九州電力の場合は、

九州電力の更新時刻
CSVファイルが更新された時刻 (日付時:分:秒)	5分刻みの時刻との差 (分:秒)	UPDATEに記載された時刻 (日付時:分)	新しく追加されたデータの時刻 (日付時:分)	更新された時刻との差 (分:秒)
2011/7/18 11:38:20	3:20	2011/7/18 11:35	2011/7/18 11:35	3:20
2011/7/18 11:43:20	3:20	2011/7/18 11:40	2011/7/18 11:40	3:20
2011/7/18 11:47:20	2:20	2011/7/18 11:45	2011/7/18 11:45	2:20
2011/7/18 11:53:20	3:20	2011/7/18 11:50	2011/7/18 11:50	3:20
2011/7/18 11:57:20	2:20	2011/7/18 11:55	2011/7/18 11:55	2:20
2011/7/18 12:02:19	2:19	2011/7/18 12:00	2011/7/18 12:00	2:19

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

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

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

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

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

とにかく、正常なデータの更新が再開する時刻を同じく自作ソフトで調べてみたのが以下です。

	東京電力 (時:分:秒)	東北電力 (時:分:秒)	関西電力 (時:分:秒)	九州電力 (時:分:秒)
2011/7/21	1:05:53	1:02:08	1:19:57	0:08:14
2011/7/22	1:07:40	1:02:17	1:20:07	0:08:42

東京電力と東北電力は、その日の1回目の更新で前日のデータを全部出した後、更新が止まり、1時過ぎに0時台の1時間のデータとともに、5分ごとのデータの更新が再開します。これも一つの割り切りだとは思います。
関西電力は、更新は止まらないのですが、中身は前日のデータという状態が続き、中身もその日のデータに切り替わるのは1時20分頃です。止まらないのはいいのですが、あまり行けてない感じがします。
九州電力は、1回だけ更新がスキップしますが、その日の2回目のタイミングから更新が再開します。圧倒的に早いです。まあ九州電力は1時間ごとのデータを出してないので、そこが他とは違いますが。

以上のように、九州電力を除いて、0～1時頃の間は正常なデータがリアルタイムで出ていません（その間のデータは再開した時点でまとめて出ます）。電気アラートでは、正常でないデータはスルーするようにしているので、再開するまで前日のデータが表示されたままになります。実用上は問題ないと思いますが、念のため。

東京電力の電力状況

noreply@blogger.com (EMO) — Fri, 01 Jul 2011 07:16:00 +0000

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

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

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

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

Netgearの省電力ハブ

noreply@blogger.com (EMO) — Thu, 19 May 2011 23:26:00 +0000

手近な機器の消費電力を測ったときに気になっていた、Buffaloの古いGbEハブ（LSW-GT-5W）をNetgearのGS105v3（ProSafe 5-port Gigabit Desktop Switch）に更新した。

これにしたのはコンパクトで真四角な金属筐体というのが最大の理由で、消費電力については最大3.2Wというぐらいしか情報がなかった。

今時のハブにはたいてい省電力機能があって、例えばBuffaloのLSW3-GT-5NSでは不使用ポートの電力オフとケーブルの長さに応じた電力カットを謳っているが、GS105v3の場合は詳しい説明がない。一応、外箱には「Auto power-down mode saves energy when port is unused」との記述があるので、不使用ポートの電力オフ機能があることは分かるが。

そこでワットモニターで消費電力を測ってみたのが以下。

	リンク速度	使用ポート数	消費電力 (W)
電源オンのみ		0	1.1
ADSLルーターを接続	100M	1	1.2
ThinkPad X61sを接続	1000M	2	1.7
ReadyNAS Ultra 2を接続	1000M	3	2.2
ThinkPad X60sを接続	1000M	4	2.7
ReadyNAS Duoを接続	1000M	5	3.2

ワットモニターの誤差もあり得るが、

基本は1.1W
使用ポートが増えるにつれ、大体0.5Wずつ増えていく
公称の最大3.2Wというのは正確

ということが分かる。なお、5ポートに接続した状態で全ポートをビジーにしてみたが（X61sでYouTubeの動画を見つつ、Ultra2上の動画ファイルを再生し、かつDuo上の動画ファイルをX60sで再生）、消費電力に変化はなかった。使用状況で何か変わるかと思ったが、そうでもないらしい。

結果としては、消費電力を公表しているLSW3-GT-5NSより、いずれの状態でも消費電力は小さく、十分な省電力性が確保されていると思う。

問題ではないが、気づいたこともあって、それはLEDの光が強いこと。

下のLSW-GT-5Wの電源LEDがぼうっと点いているのに比べて、GS105v3のLEDは眩しく光っている。5つのポートを全部使用すると最大11個のLED（電源＋1000Mの場合の各ポート2×5）が点灯する。ハブなので別にいいのだが、結構派手ではある。

東京電力のピークタイム

noreply@blogger.com (EMO) — Sun, 08 May 2011 14:39:00 +0000

TPTPコネクトの開発が一段落したので（TPTPコネクト自体の関係はSourceForgeの方で）、そもそも東京電力のピークタイムはどうなっているのか？について、改めて東京電力電力供給状況APIからスクリプトでデータを取得してまとめてみた。

大体3/26を境目に、それまで毎日のように計画停電が打たれていたのが、気温の上昇と発電能力の一部回復で需給が緩和されていき、現在に至っている。

なお、電力使用率の高い日が特別逼迫しているというより、需給予想に従って東京電力が発電能力を増減させているので、東京電力の予想よりは使用量が高かった日と見た方がいいと思う。

例えば、4/19は4月に入ってから使用量が一番高かった日だが、使用率には比較的余裕がある。これに対して、4/23は使用量はさほどでもないのに使用率は高くなっている。2日前の5/06の使用率が高いのも、連休の狭間にしては使用量が高かったということではないかと思う。

ともあれ、ピークシフト的には、

どの情報からピークタイムを得ればいいのか？
（バッテリ駆動がそれなりに長く可能として）バッテリ駆動時間をどのように配分すればいいのか？

ということが問題になるが、

東京電力の予想するピークタイム（ピーク時供給力の時間帯。グラフに横棒が引っ張ってある部分）は、時々外すが、最近では概ね安定している。
平日の日中は使用率が僅差で高止まりしているので（12時台に少し落ちる以外）、どの時間帯にバッテリ駆動すればいいのかは簡単には決め難い。

えいやっと決め打ちでもいいのだが、どうせやるならうまくピークタイムと使用率の高い時間帯に合わせられた方がいいよね、ということでTPTPコネクトの出番となるわけだが、さて。

ReadyNASとは何か

noreply@blogger.com (EMO) — Fri, 08 Apr 2011 12:00:00 +0000

ReadyNASを普通に使っている限りは全く気にする必要はないが、何か問題が起きたりしたときに、そもそもReadyNASの中はどうなってるのかということに興味が湧くのは自然だと思うので、その流れの話。

（このエントリは一続きのエントリの5/5）

4.1. ReadyNASの構成（推測）

ReadyNASが何かといえば、LinuxをOSとして稼働する/RAID構成で/NAS専用のPC、ということになる。アプライアンスのLinux機としては普通のPCに近いが、普通のPCと特に違うのは、

オンボードにOSのインストールイメージを持っていること
ブートプロセスが少し変わっていること

ただ、Netgearの人はこういう話をあまり正面から書いてくれてない。あくまでアプライアンスであってユーザーの心配することではないし、SSHでログインすれば分かる人には分かるだろう、と説明の必要を感じてないのかもしれない。したがって、自分の推測がかなり入っているし、自分はLinuxに特に詳しいわけでも何でもないので、その前提で。

本当にトラブルに陥って回復作業をしなければいけないときは、素直にNetgearのサポートに頼った方がいい。

先に用語について。ReadyNASでは、そのファームウェア＝専用にカスタマイズされたLinux＝OSのことをRAIDiatorと呼んでいる。よく似た名前でRAIDarもあるが、こちらはクライアントPCからネットワーク上のReadyNASをモニターするためのソフト。何でこんなややこしい名前にしたのか知らないが。

いきなりだが、ReadyNASの構成とRAIDiatorのアップデート/回復の関係を整理。

	場所	Duo (Sparc) (X-RAID)	Ultra 2 (x86) (X-RAID2)	RAIDiatorのアップデート/回復の影響
	場所	Duo (Sparc) (X-RAID)	Ultra 2 (x86) (X-RAID2)	Frontview /USBメモリからのアップデート (注1)	OS Reinstall (注3)	Factory default (注4)
BIOS	オンボード	NAND Flash (64MB)	Flash ROM (2MB)
Linux カーネル			NAND Flash (128MB)	書き換え
Linux インストールイメージ (RAIDiator ファイル)			NAND Flash (128MB)	書き換え
OS (Linux ユーザーランド) (RAIDiator)	HDD (2台とも)	2GB (初期に約350MB を使用)	4GiB (初期に約370MB を使用)	書き換え (注2)	OSをNAND Flashからインストール	パーティションを作成し直して（ユーザーデータは消える）、 OSをNAND Flashからインストール
スワップ		256MB	512MiB
ユーザーデータ		残り	残り
DRAM メモリ	SO- DIMM	DDR- SDRAM (初期は 256MB)	DDR3- SDRAM (初期は 1GB)

（注1）USBメモリからのアップデートを確認したのはUltra 2のみ。

（注2）既にインストールされているバージョンと同じ場合は書き換えない。

（注3）何かの事情でNAND FlashとHDDのRAIDiatorのバージョンが違う状態になった場合、自動的にOS Reinstallが行われる。ただし、これがうまく行かず、起動できない状態になることもあり、そのときは手動でOS Reinstallが必要。

（注4）そのReadyNASで稼働する状態になったHDD以外を入れた場合、自動的にFactory defaultが行われる。ただし、これがうまく行かず、起動できない状態になることもあり、そのときは手動でFactory defaultが必要。なお、同じ機種同士であればそのままのHDDで稼働する模様。

4.2. アップデート/回復手段

なぜこう言えるのかはひとまず置いて、具体的な方法について説明すると、

Frontviewからのアップデート

基本簡単。ただし、古いバージョンに戻せない制限付きのことがあるので、リリースノートに注意。

USBメモリからのアップデート

ReadyNASがまともに起動せず、Frontviewが使えない場合や、Frontviewからは古いバージョンに戻せない制限がある場合でも可能だったりする。

以下はUltra 2（x86）の場合の方法。

[参考] 非公式だが、公式FAQからリンクされている方法
Unofficial ReadyNAS USB Recovery Guide for x86-based Systems

ReadyNAS_x86_USB_Flash_Recovery-4.2.12.zipをダウンロードする。これを展開してusbrecovery.exe（NETGEAR USB Recovery Utility）を実行すればUSBメモリが作成される。

なお、このユーティリティの実行にはVisual C++ 2005 SP1 Redistributable (x86)が必要。また、これにはRAIDiatorファイル（4.2.12）が同梱されているが、同じフォルダに新しいRAIDiatorファイルをコピーすれば、実行時にそれを選ぶことができる。
このUSBメモリを前面のUSB3.0ポートに挿し、backupボタンを押した状態で電源ボタンを押して離す。電源が入って自動的にUSBメモリにアクセスが行われ、2分ぐらいで自動的に電源が落ちる（ここまでbackupボタンは押したまま）。
USBメモリを抜き、普通に電源を入れると、アップデート作業が行われて起動する。

ちなみに、自分のDuoではUSBメモリによるアップデートに成功したことは、相当粘ってみたが一度もない。どこかに問題があるのだと思う。一方、DuoにはPCと直結してTFTPでアップデートする方法があるが、Ultra 2でも同様の方法があるのかは不明。

OS Reinstall

HDDにあるOSをNAND Flashにあるインストールイメージを使って書き換えるもの。ユーザーデータには触らないので、ユーザーデータが失われることはない。

ただし、これを開始する操作はFactory defaultにごく近いので、一歩間違えるとFactory defaultになってユーザーデータは失われる。もし誤ってFactory defaultが開始されかけたときは、電源ケーブルを引き抜いてでも止めなければいけない。

以下はUltra 2（x86）の場合にOS Reinstallを開始する方法。

[参考] 日本公式サイトにある説明
ReadyNAS Ultra2 ： RAIDiator (ReadyNAS OS) の再インストール

後面のResetスイッチをピンで押した状態で電源ボタンを押して離す（Resetスイッチは押したまま）。Act以外のLEDが全部点灯したらResetスイッチを離す。
これで管理用のブートメニューに入ったので、backupボタンを3回押し、HDD2のLEDだけが点灯した状態（OS Reinstallが選択された状態）にする。ここで後面のResetスイッチを押すと、選択が確定され、OS Reinstallが開始される。

ちなみに、このブートメニューとLEDの関係は以下のようなもの（Readynas Ultra 2 how to resets etc...）。

		電源	HDD 1	HDD 2	backup (USB)
	ブートメニュー開始	●	●	●	●
1回目	Normal	●	-	-	-
2回目	Factory default	-	●	-	-
3回目	OS Reinstall	-	-	●	-
4回目	Tech Support	-	-	-	●
5回目	Skip Vol Check	●	●	-	-
6回目	Memory Test	●	-	●	-
7回目	Test Disk	●	-	-	●

（注）Actは関係ない。

なお、OS Reinstallの後も一部の設定は残ってたりするので、OSのパーティションをフォーマットしてからインストールするのではなく、上書きインストールをする模様。

Factory default

最も根本的かつ破壊的な手段で、HDDをチェックした後、全てのパーティションを作成し直した上で（ユーザーデータは消える）、OSをNAND Flashにあるインストールイメージからインストールするもの。

なお、工場出荷時の状態にリセットするといっても、RAIDiatorをアップデートしたことがあれば、NAND Flashのインストールイメージも書き換えられているので、文字通り工場出荷時の状態に戻るわけではない。

以下はUltra 2（x86）の場合にFactory defaultを開始する方法。

[参考] 日本公式サイトにある説明
ReadyNAS Ultra2 ：工場出荷時の設定への戻し方

後面のResetスイッチをピンで押した状態で電源ボタンを押して離す（Resetスイッチは押したまま）。Act以外のLEDが全部点灯したらResetスイッチを離す。
これで管理用のブートメニューに入ったので、backupボタンを2回押し、HDD1のLEDだけが点灯した状態（Factory defaultが選択された状態）にする。ここで後面のResetスイッチを押すと、選択が確定され、Factory defaultが開始される。

上記の（注4）のとおり、そのReadyNASで稼動する状態になっているHDD以外を入れた場合（空のHDDや普通のPCで使っていたHDDを入れた場合、Duo（Sparc）で稼動していたHDDをUltra 2（x86）に入れた場合、またはその逆も含まれる）は、起動時に自動的にFactory defaultが行われる。この辺は少し怖いところ。

ただし、これがうまく行かず、起動できない状態になることがある。法則性はよく分からないが、以前にReadyNASで使っていたHDDを一旦別の用に使い、再びReadyNASで使おうとしたときに起こった（RAIDarに「ルートファイルシステムが壊れています」と表示される。このルートファイルシステムとはRAIDiatorのOSのあるパーティションを指しているようなので、それがない状態では当然ではある）。

そういうときは手動でFactory defaultを開始すれば回復できた。

4.3. ReadyNASの構成に関する推測

話は戻って、ReadyNASの構成に関して。基本的に、馴染みのあるx86のUltra 2を中心に話を進める。

まずメモリの構成については、Netgearの資料に記載がある（Letter of Volatility）。これを見るまで、Ultra 2のAMIBIOSがNAND Flashにあるのか、（普通のPCのように）独立したFlash ROMにあるのか分からなかったが、答えは後者だった。

HDDのパーティション

パーティションについては、実はログ（「全てのログ」の方）に出ている。まずDuo（HDDは5400.5の320GB）の方で、「fdisk -l」の結果らしきpartition.logを見ると、

Disk /dev/hdc: 320.0 GB, 320062447616 bytes
255 heads, 63 sectors/track, 38912 cylinders, total 625121968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x53c9a337

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1              32     4096031     2048000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/hdc2         4096032     4608031      256000   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/hdc3         4608032   625105615   310248792    5  Extended
/dev/hdc5         4608040   625105615   310248788   8e  Linux LVM

Disk /dev/hde: 320.0 GB, 320062447616 bytes
255 heads, 63 sectors/track, 38912 cylinders, total 625121968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

この中のhdc1のパーティションがOSのあるルートで、hdc2はスワップ、その後ろの拡張パーティション中のhdc5にユーザーデータの入ったLVMがある。

さらに「df -h」の結果らしきdisk_usage.logを見ると、

Filesystem            Size  Used Avail Use% Mounted on
/dev/hdc1             2.0G  352M  1.6G      18% /
tmpfs                  16k     0   16k       0% /USB
/dev/c/c              294G  270G   24G      92% /c

OSのあるhdc1の使用量が分かる。また、ユーザーデータは/dev/c/cにマウントされていることも分かる。

同様に、Ultra 2（HDDは5K500.Bの500GB）のpartition.logを見ると、

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xbe56265a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              64     8388671     4194304   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2         8388672     9437247      524288   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sda4         9437248   976768064   483665408+   5  Extended
/dev/sda5         9437256   976768064   483665404+  fd  Linux raid autodetect

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              64     8388671     4194304   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2         8388672     9437247      524288   fd  Linux raid autodetect
Partition 2 does not end on cylinder boundary.
/dev/sdb4         9437248   976768063   483665408    5  Extended
/dev/sdb5         9437256   976768064   483665404+  fd  Linux raid autodetect

Disk /dev/md0: 4293 MB, 4293906432 bytes
2 heads, 4 sectors/track, 1048317 cylinders, total 8386536 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/md1: 536 MB, 536805376 bytes
2 heads, 4 sectors/track, 131056 cylinders, total 1048448 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/md2: 495.2 GB, 495272132608 bytes
2 heads, 4 sectors/track, 120916048 cylinders, total 967328384 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000


Disk /dev/dm-0: 489.8 GB, 489894707200 bytes
255 heads, 63 sectors/track, 59559 cylinders, total 956825600 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

こちらは完全にソフトウェアRAIDの状態を示していて、sda1とsdb1から成るmd0がOSのルート、sda2とsdb2から成るmd1がスワップ、拡張パーティション中のsda5とsdb5から成るmd2にユーザーデータの入ったLVMがある。

同じくdisk_usage.logを見ると、

Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              4.0G  371M  3.5G  10% /
tmpfs                  16K     0   16K   0% /USB
/dev/c/c              455G  273G  182G  60% /c

OSのあるmd0の使用量が分かる。

また、同じくmdconfig.logを見ると、

Device         : /dev/md0
Create Time    : 1296968223
Update Time    : 1299155668
RAID Level     : 1
RAID Capacity  : 4193268
Disk Size      : 4193268
Chunk Size     : 0
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda1          0        8/ 1      8388608    6 [ Active Sync ]
  2   /dev/sdb1          1        8/17      8388608    6 [ Active Sync ]

Device         : /dev/md1
Create Time    : 1296968223
Update Time    : 1299119883
RAID Level     : 5
RAID Capacity  : 524224
Disk Size      : 524224
Chunk Size     : 65536
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda2          0        8/ 2      1048576    6 [ Active Sync ]
  2   /dev/sdb2          1        8/18      1048576    6 [ Active Sync ]

Device         : /dev/md2
Create Time    : 1296968223
Update Time    : 1299155668
RAID Level     : 5
RAID Capacity  : 483664192
Disk Size      : 483664192
Chunk Size     : 65536
Disks          : 2
RAID Disks     : 2
Active Disks   : 2
Working Disks  : 2
Failed Disks   : 0
Spare Disks    : 0
State          : 1 [ Clean ]

Disk  Device         RAID Disk  Maj/Min     Sectors   State
---------------------------------------------------------------------------
  0   /dev/sda5          0        8/ 5    967330809    6 [ Active Sync ]
  2   /dev/sdb5          1        8/21    967330809    6 [ Active Sync ]

RAIDの設定が分かる。OSのあるmd0はRAID1、ユーザーデータのあるmd2はRAID5と出ているが、X-RAID2はNetgearの独自拡張らしいので、その通りに取っていいかは不明。

ちなみに、Ultra 2はRAIDiator 4.2.16で3TBのHDDに対応するが、そのためにHDDのパーティショニングが従来のMBRからGPTに変わる。その場合はどうなるかといえば、4.2.16-T33にアップデートしたUltra 2（HDDは5K500.Bの120GB）で「sgdisk -p」をすると、

Disk /dev/sda: 234441648 sectors, 111.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 316D3541-952B-44B0-ABC1-E150505DF780
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 8-sector boundaries
Total free space is 5108 sectors (2.5 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64         8388671   4.0 GiB     FD00  Linux RAID
   2         8388672         9437247   512.0 MiB   FD00  Linux RAID
   5         9437256       234436544   107.3 GiB   FD00  Linux RAID

同じく「df -h」をすると、

Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              4.0G  376M  3.5G  10% /
tmpfs                  16K     0   16K   0% /USB
/dev/c/c              102G  257M  102G   1% /c

パーティション自体はMBRのときと変わってないのが分かる。というわけで、4.2.16にアップデートしたらパーティションはそのままGPTに横滑りする仕組みらしい。なお、HDDのセクタ0はしっかりprotective MBRになっていた。

以上でHDD内の大まかな構成は分かった。

カーネルの所在

オンボードのNAND Flashについて、そこにRAIDiator（ファームウェア）のインストールイメージが置かれていることは色々なところで書かれている。例えば、Netgearの人はPro（x86）についてこう書いている。

(Re: [Readynas Pro Business] 128MB or 256MB embedded flash?)
That is just where the firmware image is stored for re-install/factory installs, you cannot use the flash in user mode. Right now the firmware image is around ~65MB. Upon system install, an OS partition is created on the hard drives that is 4GB in size. That is where all applications/configuration is stored.

また、Sparc（機種は書いてないが時期的に）については、

(Re: general interest question about the firmware)
The firmware is stored on Flash RAM on the main board. The OS is installed to a 2GB partition on the drives.

(Re: iTunes Server won't go away)
The firmware will stay as whatever you have installed. When you update the system, the firmware is written to the NAND/Flash as well, which is the source during a re-install. It won't touch your data, but will set the network IP to DHCP and admin password to default (netgear1).

HDDにインストールされたOSの使用量から見て、NAND Flashにその（たぶん圧縮された）インストールイメージが入っているのは容易に理解できる。ただ、NAND Flashの役割が単にその倉庫だけなのか、あるいはブートプロセスに関わっているのかが分からなかった。

そこで、Ultra 2のHDD（5K500.Bの500GB）のセクタ0を見てみると、

パーティションテーブルは当然あるが、ブートコードの部分は空になっている（WindowsのDiskIDが付いているが、これはX61sに接続したときに書き込まれたものだと思う）。

さらに、OSのパーティションの中を見回しても、GRUBのようなLinuxのブートローダーがないことに気づいた。つまり、普通にHDDからブートしている形跡がない。

不思議に思いながら、ブート時の記録であるdmesg.logを見ると、その冒頭に以下の記述があった。

Linux version 2.6.33.7.RNx86_64.2.2 (jmaggard@calzone) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Oct 15 13:20:46 PDT 2010
Command line: initrd=initrd.gz console=ttyS0 sk98lin.LowLatency=Off,Off reason=normal BOOT_IMAGE=kernel

実はここでLowLatencyの設定がされてたりするが、それは置いといて重要なのは以下の部分。

initrd=initrd.gz
BOOT_IMAGE=kernel

これはinitrd（ブート初期のramdiskイメージ）としてinitrd.gzを、カーネルイメージとしてkernelをロードしているらしいが、OSのパーティションにはそれらしきものはなかった。

が、この2つのファイルには見覚えがあった。それはRAIDiatorのアップデート用のUSBメモリの中で。

実はこのUSBメモリはsyslinuxでブータブルになっていて、X61sでも途中まで起動できたりする。

さらに面白いのは、この設定ファイルであるsyslinux.cfgで、その中身が以下。

serial 0 9600 0

default Normal

label Normal
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=normal

label FactoryDefault
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=factory

label OSReinstall
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=os_reinstall

label TechSupport
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=diag

label SkipVolCheck
kernel kernel
append initrd=initrd.gz console=ttyS0 reason=skip_fsck

label MemoryTest
kernel memtest

冒頭にシリアルポートの設定らしきものがあるが、その後には明らかに管理用のブートメニューと関係ありそうな記述が並んでいる。とくに、先頭のlabel Normalの部分はdmesg.logの冒頭と似ていて、カーネルイメージとしてkernelを、initrdイメージとしてinitrd.gzをロードするとの設定になっている。

ここで、ブート時にNAND Flashがどういう扱いになっているか調べてみると、ReadyNAS Pro（x86）でBIOSのブート時の画面が写っているものがあった（ReadyNAS Pro RNDP6350 Possible Flash Disk Boot Failure）。

ProのPCBにはVGAのピンが出ていて、こういう画面が出せたりするようだが、AMIBIOSがHDDを認識した後にこんな表示を出している。

Device #01 : SMI USB DISK *HiSpeed*
01 USB mass storage devices found and configured.

この「SMI USB DISK」に関して、Ultra 2のusb_devices.logに以下の記述があるのを見つけた。

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=090c ProdID=1000 Rev=11.00
S:  Manufacturer=SMI Corporation
S:  Product=USB DISK
S:  SerialNumber=AA04012700015822
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

この「Vender＝090c」で検索してみると、SMIは「Silicon Motion Inc.」を指すらしい。したがって、Proには（Ultra 2やUltra 4と同様に）Silicon MotionのNAND Flashコントローラがあり、これがブート時にBIOSでUSB接続の、たぶんブートデバイスとして認識されているのだと思う。

ということは、同じx86のUltra 2でもオンボードのNAND FlashがBIOSでブートデバイスとして認識されているのではないか、ということになる。ただ、それを直接確かめることはできないので（カーネルが起動する前のことなのでログにも残らない）、NAND Flashの中身を見られないか。

Ultra 2のdmesg.logには以下の記述があるので、NAND Flashはsdcとなっているらしい。が、色々試しても自分ではこれをマウントできず、中身は分からなかった。

scsi 4:0:0:0: Direct-Access     SMI      USB DISK         1100 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: Attached scsi generic sg2 type 0
sd 4:0:0:0: [sdc] 244736 512-byte logical blocks: (125 MB/119 MiB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 43 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Attached SCSI removable disk

ともあれ、諸々を考え合わせると、以下のような推測を立てられる。

ブート時にはBIOSがいわばオンボードのUSBメモリであるNAND Flashをブートデバイスとし、
NAND Flashから（syslinuxか何かのブートローダーを介して）Linuxのカーネル（kernel、initrd.gz）がロードされて起動し、
後はカーネルがHDD内のOSのパーティションからカーネル以外（ユーザーランド）をロードして起動する。

と、ここまで来たところで、そういうことはNetgearの人も書いている（断片的だが）のを見つけた。まずNVX（x86）についてこう書いている。

(Re: PAE (Physical Address Extention) for NVX Models)
It has some custom modules for handling the special hardware, and the kernel itself is not stored on disk, but in the firmware flash, so doing an apt-get won't do much.

また、全てのx86について、

(Re: Ultra 6 with 4.2.15 - GPT support?)
The Ultra (all x86) boot using BIOS to Internal Flash ROM. It mounts / (root) from the disks, but the boot process is in the flash.

Duo（Sparc）については、

(Re: Duo stuck in boot up flashing blue light)
The drives aren't needed for it to boot in telnet mode, it loads that boot image from the internal flash.

また別の人はNV+（Sparc）についてこう書いている。

(Re: T21: Trouble (re)booting after first application of update)
It does do the initial booting off the flash, so I suppose it's possible there are some bad blocks on the flash.

ということで、初期のブート（＝カーネルのロード）はオンボードのNAND Flashから行われることが確定。

なお、Netgearの人はブートプロセスに関してこうも書いている。

(Re: VirtualBox version of x86 RAIDiator?)
Not possible at this time. It would take much changing on the boot code. Much of it is tied to hardware addresses (firmware location etc), so it would never find the boot flash.

これを見ると、NAND Flashには普通のファイルシステムはなく、ハードウェアのアドレスを直接叩くやり方になっているのかもしれない。

ちなみに、このカーネルはRAIDiatorをアップデートするとバージョンが変わるので、一緒にアップデートされる模様。USBメモリからアップデートした場合でもUSBメモリ中のkernelとは違うので、単純なコピーではない。

4.2.13: 2.6.33.6.RNx86_64.2.1 #1 SMP Tue Jul 27 13:21:19 PDT 2010
4.2.14: 2.6.33.7.RNx86_64.2.2 #1 SMP Wed Sep 29 17:22:45 PDT 2010
4.2.15: 2.6.33.7.RNx86_64.2.2 #1 SMP Fri Oct 15 13:20:46 PDT 2010

シリアルポート

Duoの後面には診断用のシリアルポートが付いている（ReadyNAS DUO Reset Switch Location Image）。同じものはUltra 2の後面にもある。4pinのもので、ピンアサインも分かっているようなので（Running own code on the Infrant ReadyNAS）、もし興味があれば。

4.4. ReadyNASのHDDをPCで直接見る可能性

DuoとUltra 2は2台のHDDによるミラーリングなので、原理的には、どちらか1台を普通のPCに繋げばユーザーデータを見ることはできる。

ただし、DuoはハードウェアRAID（たぶん）のせいか、パーティションは普通のLinuxのPCと変わらないが、ユーザーデータはLVMで管理されていて、かつブロックサイズがx86のLinuxでは標準でサポートされてない16KBなので、これを読むのに四苦八苦してたりする（ReadyNAS Data Recovery - VMware recovery toolなど）。なお、暗号化はされてない。

以下はDuo（HDDは5K500.Bの120GB）のユーザーデータのある/dev/c/cを「dumpe2fs -h」したもの。

dumpe2fs 1.40.11 (17-June-2008)
Filesystem volume name:   c
Last mounted on:          <not available>
Filesystem UUID:          8adbb446-8d4d-4ec1-a6e1-2223841c5417
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              3590400
Block count:              7180288
Reserved block count:     0
Free blocks:              7089875
Free inodes:              3590376
First block:              0
Block size:               16384
Fragment size:            16384
Reserved GDT blocks:      128
Blocks per group:         65528
Fragments per group:      65528
Inodes per group:         32640
Inode blocks per group:   510
Filesystem created:       Wed Feb 16 19:24:25 2011
Last mount time:          Wed Feb 16 19:39:31 2011
Last write time:          Wed Feb 16 19:39:31 2011
Mount count:              4
Maximum mount count:      -1
Last checked:             Wed Feb 16 19:24:25 2011
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      552799a4-355e-4415-9b7c-2c78b4f7772b
Journal backup:           inode blocks
Journal size:             512M

また、Ultra 2の方はソフトウェアRAIDなので、そもそもパーティションが違う。ただ、ブロックサイズは4KB。

以下はUltra 2（HDDは5K500.Bの120GB）のユーザーデータのある/dev/c/cを「dumpe2fs -h」したもの。

dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   <none>
Last mounted on:          /c
Filesystem UUID:          01ce2742-6b27-49ea-b11a-ec7e7290767b
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1675264
Block count:              26804224
Reserved block count:     0
Free blocks:              26649527
Free inodes:              1675241
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              16
RAID stripe width:        16
Flex block group size:    16
Filesystem created:       Wed Feb 16 18:12:28 2011
Last mount time:          Wed Feb 16 18:30:05 2011
Last write time:          Wed Feb 16 18:30:05 2011
Mount count:              5
Maximum mount count:      -1
Last checked:             Wed Feb 16 18:12:28 2011
Check interval:           0 (<none>)
Lifetime writes:          543 MB
Reserved blocks uid:      0 (user unknown)
Reserved blocks gid:      0 (group unknown)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      fe87f508-0a80-4ad7-a643-23ffa57bc308
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0000001e
Journal start:            1

正直、普段からこういう環境に親しんだLinux使いの人でもなければ相当苦労すると思う。いざとなればLinuxのPCに繋げれば読める、というのは甘ーい幻想。お任せのアプライアンスなNASのために、それだけの苦労をするのも本末転倒な気がするので、バックアップなど運用上の注意で何とかするのが結果的には楽だと思う。

なお、ReadyNAS本体が故障してHDDが生き残った場合、そのHDDを読む方法は、Netgearの公式では、同じ機種のReadyNASを入手してきて同じ順番で差せばそのまま稼働する、というもの。絶対どうしても、という場合はこれが確実かつ安全策ではある。

いずれにせよ、本体がハードウェア的に壊れた様子はないが、起動しなくなったり、OSがおかしくなったりした場合には、まずはOS Reinstallを試してみるのが基本。

バッテリー最強構成

noreply@blogger.com (EMO) — Mon, 28 Mar 2011 13:07:00 +0000

一日を通したピークシフトを考えた場合、大容量バッテリーだけでは持続時間がやや物足りないので、拡張ライフバッテリー（底面に貼り付けるもの）を購入した。これでThinkPad X6x用のバッテリーは全種類を揃えたことになる。

1. X6x用バッテリー比較

12時の位置から時計回りに、拡張ライフバッテリー、標準の4セル拡張容量バッテリー、8セル大容量バッテリー、4セルスリムラインバッテリー。

この拡張ライフバッテリー、表面積はやたらでかいものの、持ってみると予想を裏切る軽さ。ずっしりした大容量バッテリーと比べると歴然たる差で、中は空いているのが分かる。

それぞれのバッテリー詳細情報は以下のとおり（スリムラインバッテリーは4本あったうちの一番新しいもの）。

4セルスリムラインバッテリー	4セル拡張容量バッテリー
8セル大容量バッテリー	拡張ライフバッテリー

スペックをまとめると以下のようになる。

	セル	FRU	重量 (g)	定格容量 (Wh)	比率 (注2)	持続時間 (注3)	満充電容量 (Wh)	サイクルカウント
4セルスリムラインバッテリー	角形×4	42T4629	189	28.80	0.77	1.6	23.29	55
4セル拡張容量バッテリー	シリンドリカル×4	42T4570	240 (注1)	37.44	1.00	2.1	37.44	23
8セル大容量バッテリー	シリンドリカル×8	42T4632	450 (注1)	74.88	2.00	4.2	75.96	8
拡張ライフバッテリー	不明 (角形×4?)	40Y7904	365	28.08	0.75	1.6	28.08	1

（注1）スペーサーを含む。

（注2）拡張容量バッテリーの定格容量を1とした場合の比率。

（注3）大容量バッテリーの持続時間を4.2とし、定格容量の比率から計算したもの。

バッテリ持続時間は使い方によって大きく変わるが、このX61s（CPU: Core2Duo L7700 1.8GHz、メモリ: 4GB、Windows 7 64bit）では、自分の使い方では大容量バッテリーで4時間強といったところ。

省電力マネージャーの計算ではこれぐらい。ただし、これはふらふら変わるので、たいして当てにはならない。

これでLenovoのバッテリー時間対応表の半分ぐらいになる。
このスリムラインバッテリーはあまり優しい使い方をしてなかったので、サイクルカウントの割に満充電容量の落ちが大きい。
大容量バッテリーの定格容量は拡張容量バッテリーの丁度倍で、セル数を反映している。
この拡張ライフバッテリーは、新品だが、製造日は一番古い。つまり蔵出し品で、そんなに生産されなかったらしい。定格容量はスリムラインバッテリーよりやや小さい程度なので、たぶん同じ角形セル×4の構成で、セル自体の型が少し古いのではないかと思う。

拡張ライフバッテリーはもっと容量があるものだと勝手に思い込んでいたので、スリムラインバッテリーと同程度というのは拍子抜けではある。

それはともかく、大容量バッテリー＋拡張ライフバッテリーというX6xのバッテリー最強構成でも持続時間は6時間ぐらいなので、一日の日中をずっとバッテリ駆動させるのは無理で、やはりスポット的にバッテリ駆動を組み込んだピークシフトプランにせざるを得ないと分かった。

2. 拡張ライフバッテリーを追加すると

拡張ライフバッテリーは、省電力マネージャーに出るとおりセカンドバッテリーという扱いになり、これに対して普通に本体の後ろに付くバッテリーはメインバッテリーとなる。これらの違いは、放電と充電の両面でメインバッテリーが優先されるということにある。

まず放電のときは、セカンドバッテリーの方から使われ、その後にメインバッテリーが使われる。これにより、使い終わったセカンドバッテリーを取り外して軽くすることができる。つまり、航空機のドロップタンクと機内燃料タンクの関係と同じ。

最初はメインバッテリー（これは大容量バッテリー）は使われず、

セカンドバッテリー（拡張ライフバッテリー）の方から使われ始める。

次に充電のときは、メインバッテリーの方から充電され、それが終わってからセカンドバッテリーが充電される。

最初にメインバッテリーの充電が始まるが、	セカンドバッテリーの方は放置。
メインバッテリーが満充電になってから、	セカンドバッテリーの充電が始まる。

ということで、拡張ライフバッテリーを付けたときに充電が同時に行われると消費電力がどうなるのか気になっていたが、充電は（放電も）片方ずつ行われるので、そういう問題は起こらない。

3. ワットモニターでチェック

サンワサプライのワットモニターを使ってX61sの消費電力を確認してみた。

[参考]
家電Watch: 家電製品ミニレビュー: サンワサプライ「ワットモニター」～いますぐにできる、数十ワットの“節電募金”

しばらく計測していて気づいたのは、バッテリ充電中は、その空き容量によってバッテリに流れる電流（A）が変わり、それに伴って消費電力（Ｗ）も変わること。また、バッテリによる差も結構ある。

		消費電力(W)
		充電していない	充電中バッテリ空き容量(注1)
		充電していない	50%	20%	10%	5%
AC駆動中 (LCDオン) (注2)	4セル拡張容量バッテリー	17～21	53	41	25	23
	8セル大容量バッテリー		60	48	34	25
	拡張ライフバッテリー		49	39	30	25
AC駆動中(LCDオフ、外部ディスプレイ使用)		15～18
ピークシフト機能によるバッテリ駆動中		0.4
電源オフ (待機中)	WOLオフ	0.7
電源オフ (待機中)	WOLオン	1.1

（注1）小刻みに変動するので、大体これぐらいを中心に動くという数字。

（注2）ディスプレイ・ブライトネスを15段階中の6に設定。

通常のAC駆動中は低消費電力のノートPCでも、バッテリ充電中は消費電力が跳ね上がる。
充電中は、放電したてで空き容量が大きいと消費電力も大きく、充電が進んで空き容量が小さくなるにつれ消費電力も小さくなっていく（充電速度も遅くなって……）。
容量の大きいバッテリーほど、充電中の消費電力も大きい。大容量バッテリーのときなどはACアダプターの容量（65W）の上限に近い。
ピークシフト機能によるバッテリ駆動中にも、わずかながら電力の消費はある。
LCDのオン/オフによる差はそれほど大きくない。
待機中はWOLオンの方が消費電力が高い。これは理解できる。

これからピークシフト実行時の消費電力のイメージを描いてみると、大容量バッテリーの場合はこんな感じ。

さらに、大容量バッテリー＋拡張ライフバッテリーの最強構成の場合は、大容量バッテリーの充電終了後に拡張ライフバッテリーの充電が行われるので、充電の山が2回来ることになる。

いずれも一見して分かるとおり、ピークシフト実行中に通常のAC駆動分を節電する代償として、バッテリ充電時にはその倍以上の電力を消費するわけで、充電を始めるタイミングはよく考える必要がある。

ついでに、手近な機器も計測してみた。

		消費電力(W)
LCDディスプレイ (Eizo S2110W)	ブライトネス5%	40
	ブライトネス50%	59
	ブライトネス100%	66
	未入力時	1.3
	電源オフ(待機中)	0.6
PCスピーカー(Bose MediaMate II)		4.5～5
ReadyNAS Ultra 2 (5K500.B-500×2)	アイドル時	19～20
	使用時	20～22
	スピンダウン時	17.8
	電源オフ(待機中、WOLオン)	1
	電源オフ(待機中、WOLオフ）	2.8
ReadyNAS Duo (5400.5-320×2)	アイドル時	12～13
	使用時	13～15
	スピンダウン時	10.6
	電源オフ(待機中)	0.4
プリンター (Canon MP630)	アイドル時	5
プリンター (Canon MP630)	電源オフ(待機中)	0.4
ハブ(Buffalo LSW-GT-5W)		6.5
ADSLルーター(Aterm WD701CV)		5.8

LCDディスプレイの消費電力が馬鹿にならない。X61sに接続して使ってきたが、本体の倍も消費していたとは……。
BoseのPCスピーカーには電源スイッチがなく、少し気になっていたが、入力がなくても音量に関係なく消費していると分かった。よって、途中に電源スイッチを挟むことにした。
ReadyNAS Ultra 2は、ノートPC並みに消費することが分かった。Atom機だからか。待機中はなぜかWOLオフの方が数字は高い。普通は逆だと思うが、変なことを見つけてしまった。
ReadyNAS Duoは、さすがというべきなのか、Ultra 2より低消費電力。
ハブも新しい省電力のものに換えたいところ。数字はたいしたことないが、常時通電しているものだけに。
ADSLルーターも数字は低くないが、レンタル品だし、これを切るわけにもいかず。

4. 拡張ライフバッテリーを見る

拡張ライフバッテリーについてはそんなに情報が出てないので、少しだけ紹介。

大容量バッテリーと一緒にX6x本体に付けたときと同じ状態に重ねてみると、こんな位置関係になる。

本体との接続にはウルトラベースなどとのドッキング用コネクタを使用するが、他のバッテリーと同じ端子も付いている。たぶんバッテリーチャージャー用。

スリムラインバッテリーと一緒にX61sに付けたところ。隙間が空いて見えるが、中で足が突いているのか、とくにがたつきはない。

以下、大容量バッテリーと一緒に付けた状態。

裏側から見るとかなりぼてっとした感じになるが、表側から見ると意外とすっきりまとまる。日常的に付けていても違和感はなさそう。

ヤシマ作戦@ThinkPad（補足）

noreply@blogger.com (EMO) — Sat, 26 Mar 2011 03:22:00 +0000

ThinkPadのピークシフト機能について補足を少し書きます。

1. Lenovoからの呼びかけ

節電に関して、Lenovoからピークシフト機能の活用を呼びかけています。

（レノボ・ジャパン株式会社公式Facebookのウォールより）

ただ、どの機種であればピークシフト機能が使えるはずなのか、という点ははっきりしません。2006年発売のX60sでも使えているので、たいていの機種で行けそうな気はしますが。

2. メディアでのリバイバル

これまで幾つかの記事でピークシフト機能の利用に言及がありました。これでピークシフト機能の存在が呼び覚まされたと思います。

PC Watch: 本田雅一の週刊Mobile通信: 電力消費のピークシフトについて考える
(記事中で前のエントリに言及いただきました)
PC Watch: 元麻布治晴男の週刊PCホットライン: あのピークシフトをもう一度
コデラノブログ4: これからの日本の姿

東京電力が需給状況を毎時間ごとに知らせるようになったので、これとピークシフト機能を連動させることが考えられます。ただ、必要なのは限られたバッテリ駆動時間をどの時間帯に振り向けるべきかという問題への解なので、リアルタイムで連動させるいいアイデアというのはすぐに思いつきません。

リアルタイムでなければ、例えば、毎晩、その日の（または前の週の同じ曜日の）需給状況を自動的に取り込んで翌日のピークシフトプランを作成し、それを省電力マネージャーにインポートさせる、とかでしょうか。いずれにせよ、何かすばらしいメソッドが出てくるのを期待してます。

3. 一日を通したピークシフト

とりあえず夕方18～19時の時間帯をターゲットに考えてましたが、東京電力の需給状況を見ると朝9～10時にもピークがあり、また、今年の夏も電力不足となることが避けられず、そのときは14時前後がピークのようです。

ということで、理想的なピークシフトのためには、夕方だけでなく一日を通してどの時間帯にバッテリ駆動時間を振り向けるかを考える必要が出てきます。基本的な方針としては、

バッテリ充電は夜間（22時～翌日8時ぐらい）に行う。
日中は基本的にAC駆動で、ピーク時にバッテリ駆動に切り替える。
日中のバッテリ充電の継ぎ足しはなるべく避ける（その方がバッテリにも優しい）。

具体的には、現在の朝と夕方のピークに対応する場合、ピークシフトのスケジュールを2回組むことになります。

朝の終了時間（＝バッテリ充電禁止を解く時間）は、ピークシフトのスケジュールが重なるとエラーになるので、夕方の開始時間の1分前にしてある。
夕方のバッテリ駆動の開始時間。
日中のバッテリ充電禁止を解き、充電を開始させる時間。

1回目のピークシフトのスケジュール。

週末は大丈夫そうなので、平日だけを指定できるよう「毎週」にした。
日曜日と土曜日を外してチェックする。
朝のバッテリ駆動の開始時間。
バッテリ駆動を1時間30分として、その終了時間。
日中にバッテリ充電をさせないため、充電禁止を解く時間（朝のピークシフト終了時間）を夕方の開始時間まで伸ばす。ただし、スケジュールが重なるとエラーになるので、夕方の開始時間の1分前にした。この1分間は充電が行われるが、仕方がない。

2回目のピークシフトのスケジュール。

朝と揃える。
朝と揃える。
夕方のバッテリ駆動の開始時間。
バッテリ駆動を2時間30分として（朝と合わせて4時間）、その終了時間。
バッテリ充電禁止を解く時間。この時点で夜間のバッテリ充電が始まる。

こんな感じで、一日の間に複数のバッテリ駆動時間を入れたピークシフトプランにできます。

なお、ピークシフトの間に、バッテリ駆動中か、AC駆動中かつバッテリ充電禁止中かは、コンセントのアイコンにカーソルを合わせたときのポップアップで確認できます。バッテリ駆動中の場合は「現在放電しています」と出ます。

これが、AC駆動中かつバッテリ充電禁止中の場合は「現在充電禁止になっています」と出ます。

とりあえず。

ヤシマ作戦@ThinkPad

noreply@blogger.com (EMO) — Sat, 19 Mar 2011 11:26:00 +0000

東日本大震災を受けての東京電力と東北電力の計画停電に関して、節電（とくにピーク時の）が求められてますが、この地域のThinkPadユーザーの方々に、その一つとしてThinkPadの「ピークシフト機能」を活用することを提案します。

勿論、ノートPCの消費電力など、暖房器具や調理器具に比べればかわいいものですが、たとえ1台1台の節電によるメリットはたいしたことなくても、台数が増えれば意味がなくもないと思いますし、逆にデメリットの方は多少バッテリ寿命が縮まる以外にはないので、十分やる価値はあると思います。

また、最近はノートPCをあまり持ち歩かなくなって、バッテリ寿命が温存されているThinkPadが多いのではないかと思います。この非常時に際して、その力を発揮させてみてはどうでしょうか。

1. 省電力マネージャーによる「ピークシフト機能」

ThinkPadの電源管理ソフトである省電力マネージャーには「ピークシフト機能」が付いています。これを使うと、ACアダプターを差したままでも、予め設定した時間が来ると自動的にバッテリ駆動に切り替え、その時間が過ぎるとまた自動的にAC駆動に戻す（バッテリは充電される）ことが可能になります。これにより、その時間の間の消費電力を減らし、ピークを緩和することができます。

2. 前提

省電力マネージャーにピークシフト機能が付いたのは、今年2月にリリースされた以下のバージョンから。何というタイミング！

Windows Vista / 7用: Ver.3.40（最新はVer.3.45）
Windows XP用: Ver.1.90（最新はVer.1.95）

このバージョンでサポートされているのは、大体2005年頃に発売された機種～現行機種です。2桁の世代では以下の機種です。

Xシリーズ: X32, X40, X41, X41 Tablet, X60, X60s, X60 Tablet, X61, X61s, X61 Tablet
Tシリーズ: T43, T43p, T60, T60p, T61, T61p
Rシリーズ: R51e, R52, R60, R60e, R61, R61e
Zシリーズ: Z60m, Z60t, Z61e, Z61m, Z61p, Z61t
Gシリーズ: G50

ただし、これら全てで「ピークシフト機能」が正しく動作するかは分かりません（Ver.3.45のリリースレターを見る限り、X120eでは動作しないことになっているようですが）。

自分の手許では以下の環境で動作を確認しました。ただし、なぜか新しいVer.3.45とVer.1.95では「ピークシフト機能」が表示されなかったので、古いVer.3.40とVer.1.90を使用しています。

Ver.3.40(Windows Vista / 7用):
- X61s上のWindows 7 64bit 無印/SP1
- X60s上のWindows 7 32bit SP1
Ver.1.90(Windows XP用):
- X60s上のXP 32bit SP3

なお、これらのダウンロードリンクは既に新しいバージョンに更新され、消えてますが、サーバー上には残っているのでダウンロードはできます（3/19現在）。

Ver.3.40(Windows Vista / 7用):
- リリースレター: http://download.lenovo.com/mobilesjp/83u415j0.txt
- インストールファイル: http://download.lenovo.com/mobilesjp/83u415j0.exe
Ver.1.90(Windows XP用):
- リリースレター: http://download.lenovo.com/mobilesjp/83u715j0.txt
- インストールファイル: http://download.lenovo.com/mobilesjp/83u715j0.exe

[追記]

対応機種については、その後の展開があったので、こちらをご覧ください。

3. 設定方法

以下はThinkPad X61s上のWindows 7でVer.3.40の場合ですが、XP上でも基本的に同じです。

省電力マネージャーを開いて「ビューの切替」で「アドバンス」モードにする。上のタブから「電源スケジュール」を選び、「新規」のボタンを押す。
「スケジュールを編集」のウインドウが開くので、各項目を設定する。
1. 名前は適当で可。
2. 「処置」はプルダウンリストから「ピークシフト機能」を選ぶ。
3. 実行間隔はとりあえず「毎日」にチェック。週末などは逼迫しないようなら、「毎週」にして右の「日時」から実行する曜日を指定するのもアリかもしれない。
4. 有効期間の開始の日は、自動的に今日の日付が入る。なお、数字の右にある上下のカーソルがうまく働かないときには、数字をハイライトにして直接打ち込めばいい（以下同じ）。
5. 有効期間の終了の日は、とりあえず4月一杯にするなど。今後の状況を見て判断。
6. バッテリ駆動の開始時間は、18～19時がピークと言われているので、それをコアタイムにしてバッテリの持続時間を考えて判断すればいいと思う。このX61sは大容量バッテリを付けていて4時間強は持つので、17～21時の4時間としている。
7. バッテリ消費（＝バッテリ駆動）の終了時間。
8. 充電禁止の終了時間は、バッテリ駆動の終了時間~~に合わせればいい。~~と同じか、それ以降にすればいい。この時間から通常のAC駆動の電力＋バッテリ充電用の電力を消費するようになるので、この終了時間は~~より後ろにずらしてもいいかもしれない。~~なるべく後ろにずらし、電力需要の落ちる時間帯にした方がいい。とりあえず22時に変えた。
9. バッテリ駆動の開始時間になる前にメッセージ（下記）を出すようにできる。とりあえず10分前にした。
設定後、下の「OK」を押して保存。
「電源スケジュール」に戻ったところ。設定した時間などを確認して、下の「適用」を押す。
これで、指定した開始時間の10分前になるとメッセージが出て、カウントダウンが始まる（上記の設定で出ないようにすることも可）。
開始時間になるとメッセージが変わる。

バッテリ駆動中はタスクバーにあるアイコンが変わる。これは開始前。

開始すると、コンセントのアイコンが緑になる。
終了時間になるとAC駆動に戻る。

[修正]

バッテリ充電が始まると電力消費が跳ね上がることが分かったので、充電禁止の終了時間はなるべく後ろにずらした方がいいと変えました。

4. その他

このピークシフト機能による消費電力の低減は、所詮、暖房器具などとは比較にならないので（ThinkPadのACアダプターはほとんどが100W以下）、そちらの対策を取った上での話です。

[参考]
誠 Biz.ID: 3分LifeHacking: 節電の参考に――電気製品の消費電力まとめ
別にこの機能を使わなくても、手動で電源コードを抜けば同じことですが、自動化して手のかからないようにした方が、負担感も少なくなって、より多くの人にしてもらいやすくなると思います。
そもそもピーク時にPCを使わなければいいという意見もあると思いますが、なるべく両立できるようにした方が、負担感も少なくなって（以下同文）。
ピーク時に限らない節電の観点からは、省電力マネージャーの設定でCPUの最高速度を落とすなどすると効果的です。このX61sでは「最低速」にしていますが、日常的な使用で遅いと感じることはまずありません。ついでに、自分はNASのない生活に戻りました。

参考までに、ピークシフト機能は2002年頃から企業向けに提供されてきたものです（今年になって省電力マネージャーに入るまでの経緯は知りませんが）。

[参考]
Lenovo環境トピックス
PC Watch: 元麻布春男の週刊PCホットライン: パソコン電源もオフピーク。IBMの新しい電源制御プロジェクト
PC Watch: 元麻布春男の週刊PCホットライン: 深夜電力で充電できるように進化したピークシフト

同様のピークシフト機能は東芝のノートPCにもあるようなので、Dynabookユーザーの方々は試されてはどうでしょうか。

[追記]

ピークシフト機能による効果を試算してみました。ただし、荒い仮定による計算なので、その点はご留意ください。

まず日本の国内PC市場へのLenovoの出荷台数は、IDCの発表（2010年国内クライアントPC市場実績値を発表）によれば2010年は99.1万台、2009年は61.0万台です。

2008年以前のデータはありませんが、この2年間に出荷されたものならほとんどが現役だと思いますので、この合計160.1万台を計算のベースにします。なお、この中にはデスクトップ機や、Lenovo Gシリーズ、IdeaPadも入っているはずですが、内訳が分からないので措いておきます。
このうちの何台が東京電力と東北電力の管轄地域で稼働しているかですが、2010年の国勢調査の速報値から計算すると、東京電力の地域（静岡県は富士市以東とした）の人口が43,797,046人、東北電力の地域の人口が11,710,010人で、この合計55,507,056人は全人口の43.3%に当たります。

乱暴ですが、ThinkPadの地域ごとの稼働台数もこの人口比に従っているとすれば、1,601,000×0.433＝693,233(台)が東京電力と東北電力の地域に存在することになります。
ThinkPadの主力は数の上では基本的に据え置きのTシリーズやRシリーズだと思いますが、このACアダプターの容量90Wを基準とすれば、消費電力の合計は693,233×90＝62,390,970(W)≒6.2(万kW)となります。

さて、この数字について、最大値詐欺（まず起こらない極端な最大値だけ出して大げさに見せる）とならないようプラス要因とマイナス要因を考えると、まずプラス要因としては、

2005～2008年の4年間に出荷されたThinkPadも計算に入れれば、その相当数は既に現役でないとしても、かなり増える可能性がある。

次にマイナス要因としては、

出荷台数にThinkPad以外がどれだけ入っているか分からない。
ThinkPadは企業ユーザーが多いと言われるが、夕方のピーク時は元から就業時間外で稼働してないものが多いかもしれない。一方、これぐらいの時間なら平気で仕事をしていることも……。
ACアダプターの容量一杯を常に消費しているわけではなく、通常時はもっと低い。

これらを考え合わせると、まあ当たらずとも遠からずというぐらいの数字ではないかと思います。

いずれにせよ、6.2万kWというのは、電力の不足分として取り上げられる数字に比べれば小さなものですが、ピークシフト機能を使うことで大きなデメリットがあるわけでもないので、自分としてはやる価値はあると考えています。

（このエントリには補足があります）

ReadyNAS的クラウド

noreply@blogger.com (EMO) — Sat, 19 Mar 2011 04:00:00 +0000

これをクラウドというのかよく知らないが、Pogoplugがパーソナルクラウドとして売り出していて、それと基本的に同じ機能なので。要はLAN内のNASに外のインターネットから簡単にアクセスできる機能だが、ReadyNASではReadyNAS Remoteがそれに当たる。

これ自体はDuoでも使えるが、非力なDuoではやる気にならなかった。Ultra 2では初めからAdd-onに入っている。

（このエントリは一続きのエントリの4/5）

5.1. 手順

ReadyNAS Remoteの準備は簡単。ネットワークに関する設定は不要。

クライアントソフトをNetgearからダウンロードして、クライアントPCにインストール。そのまま初回起動時にアカウント登録をする。
FrontviewのサービスからReadyNAS Remoteを有効にする。その管理画面を開き、登録したアカウントのメールアドレスで検索して、出てきたら接続を許可する方に移して保存する。これで準備完了。

接続するときは、

PCの方でReadyNAS Remoteを起動するか、既に起動していればタスクトレイに出るアイコンを右クリックして「Log In」を選ぶと、（ReadyNAS Remoteの管理サーバーに）ログインしたと表示が出る。続けて、自動的に自分のReadyNASのホスト名が出てオンラインになったと表示されれば、接続完了。
同じように「Connect to ReadyNAS...」を選ぶと、エクスプローラにReadyNAS Remoteのアイコンが出現するので、これを開けば共有フォルダにアクセスできる。後は普通のエクスプローラと同じ。

5.2. 接続経路

速度や安定性を考えると接続経路がどうなっているかが気になるが、

接続したときに表示されるIPアドレスを調べたところ、
- whoisしてみると、クライアントPC、ReadyNASともにアメリカのアドレスになっていた。
- tracertなどをしてみると、このアドレスは（見かけ上は）どこかを中継しているわけではなく、それぞれが直接持っている形になっていた。
- Microsoft Network Monitorで観察すると、クライアントPCとReadyNASの間の通信はこのアドレス間でSMBなどのプロトコルによって行われていた。
- tracertしてみると、この通信は（見かけ上は）直接行われていた（ホップ数は1）。
ReadyNAS Remoteを有効にした状態のReadyNASにログインしてnetstatしたところ、外のIPアドレス（複数）と繋がっていた。

このアドレスをwhoisしてみると、アメリカの会社になっていた。試しにこのアドレスにブラウザでアクセスすると、繋がったのはReadyNAS Remoteのクライアントソフトから「View Profile」を選んだときと同じページだった。

ということで、このIPアドレスがReadyNAS Remoteの管理サーバーであることが確定。
クライアントPCを持ち出して外のインターネットから接続しているとき、インターネット接続状態が悪くてサーバーとの接続が切れると、ReadyNASとの通信も止まる。

ということから考えるに、ReadyNAS RemoteではクライアントPCとReadyNASを共に管理サーバーに接続させた状態で、それぞれに仮想のIPアドレスを割り当て、その間を管理サーバーが中継しているのではないかと思う。

5.3. 速度

前提として、ReadyNASのある自宅のLAN（eAccessのADSL接続）からSpeedtest.netでアメリカ西海岸のサンノゼと東海岸のボストンとの速度を計ると、こんな感じ。

まあ速くはない。とくに上り側は。

E-Mobile

外でのモバイル用には基本的にE-Mobileを使っているが、アダプターが古いこともあって（D01NX）、基本的に速くはない。

このアダプターでE-Mobileに接続し、ブラウザでウェブを見るぐらいなら何とかという状態で試したところ、ReadyNAS Remoteの管理サーバーとの接続がぷちぷち切れて使い物にならなかった。

違う場所からE-Mobileの接続が比較的安定している状態で、まずE-Mobile自体の速度を計ると、

この状態でReadyNAS Remotoに接続し、エクスプローラでファイルを転送中に「詳細」を開いてスピードを読むと、大体こんなもの。

ReadyNAS --> クライアントPC： 100KB/s前後
クライアントPC --> ReadyNAS： 40KB/s前後

決して速くはないが、数MBのファイルの出し入れ程度なら、少し待たされるが使えないこともない。ただし、通信がReadyNAS Remoteで占有されてしまうらしく、同時にブラウザでウェブを見たりするのは難しかった。

Freespot

比較のため、公衆無線LANではどうかということで、Freespotの使える店に行ってみた。

そこでの無線LANの速度を計ると、上り側が割と速かった。

この状態で同じくエクスプローラで転送してみると、

ReadyNAS --> クライアントPC： 120KB/s前後
クライアントPC --> ReadyNAS： 800KB/s前後

ReadyNASからのリードはあまり違わないが、ライトは格段に速い。その分、ストレスなくファイルの出し入れができた。

ということで、ReadyNASからのリードはたぶん自宅のLANの上り速度がボトルネックになっていると思う。一方、ReadyNASへのライトはクライアントPCからの上り速度がボトルネックになっていることが分かる。したがって、この両方の速度がもっと速ければ、ReadyNAS Remoteの速度も上がる可能性が高いと思う。

5.4. まとめ

ReadyNAS Remoteは（インターネット接続環境がよければ）十分使える。Pogoplugにあるような便利機能も、~~スマートフォン用のクライアントソフトもないが~~、追加投資なしで使えるNASの機能としては、まあいいかなと。

最後にReadyNASの回復に関することを。

[追記]

ReadyNAS RemoteのAndroid用アプリが出てた（ReadyNAS Remote）。

AtomなReadyNASの動作音

noreply@blogger.com (EMO) — Sat, 12 Mar 2011 12:23:00 +0000

静音性は自分にとって重要な要素で、NASは稼働しっぱなしということが多いだけに問題になり得るところだが、Ultra 2の動作音はどうか。

（このエントリは一続きのエントリの3/5）

3.1. ファンの回転音

一番気がかりだったファンの回転音については、しばらく使った範囲ではあまり気にならない。というより、Ultra 2を自分から直線距離で2mぐらいの場所に置いているが、稼働中ということを音で意識させられることがあまりない（アクセス中のHDDが出す音は除く）。

これは第一に、冬場なので当てにはならないが、Ultra 2では平常時のファンの回転数が割と低いことがある。

起動時の高速回転は別として、平常時で（スピンダウンはしていない）800から900RPM前後、スピンダウン時には600RPMぐらいまで下がることもあった。負荷をかけていると1000RPMを越えることもあるが、そんなに長くは続かない。

音の感じ方は環境と、何より個人差によるところが大きいが、ファンの風切り音は一般的には1000RPM以下になると少し離れれば聞こえないレベルになる。その意味では、Ultra 2のファンは聞こえないレベルにある時間が長い。

第二に、回転音が低くてもジジジ……と耳障りな軸音を発するファンがあり、まさにDuoの標準ファンがそうだったが、そういう軸音がUltra 2の標準ファン（Delta AFB0912HH）にはない。

結果的に、現在のところ、標準ファンでもまあ十分な静音性が確保されていて、その点は思い切って92mmファンにしたNetgearの設計の勝利という気がする。実は交換用にと買っておいたファンがあるのだが、出番はないかもしれない。

勿論、ファンの回転数は気温やかかる負荷によって変わってくると思うので、夏場を超えるまでは速断できない。ただ、もし回転数が高止まりするようになっても、Ultra 2ならまだ打つ手がある。つまり、設置場所を遠ざけてしまえばいい。

3.2. 遠隔から電源オン/オフ

Ultra 2はWake On LAN（WOL）に対応しているので、完全な遠隔操作が可能になった。そのため、普段は全く姿が見えないような場所に隔離しても、全ての操作が行える。

といっても、ReadyNASのRAIDarにはQNAPの管理ソフトなどのように電源オン/オフする機能はないので、自分で準備する必要があるが。

電源オン

普通にWOLのMagic Packetを送ればいい。例えばMagicSendはコマンドラインで操作できるので、MagicSendと同じフォルダに以下のバッチファイルを入れておく。

magicsend [ReadyNASのMACアドレス]

これにショートカットを張っておけば、そこから一発で起動できる。なお、WOLに対応しているのはLAN1のコネクタの方だけなので注意。

電源オフ

Frontviewに入らなくてもできる方法をNetgearの人が紹介している（Newbie question: Remote Shutdown...）。なお、これはSparcのDuoでも可能なもの。

以下の3つをダウンロードする。
要はCurlを使いたいわけだが、これはOpenSSL上で動き、OpenSSLにはVisual C++ 2008 Redistributableが必要というわけ。全てWin32版であることに注意。Visual C++ 2008 Redistributableは既に入っていれば不要だが、OSが64bitだと入っているのはx64の方だったりするのが落とし穴。
Visual C++ 2008 Redistributableをインストールの後、OpenSSLをインストールする。Curlを展開。
Netgearの人が示したスクリプトにならってバッチファイルを作る。

curl -u admin:[管理者パスワード] -k -d command=poweroff -d shutdown_option=1 -d OPERATION=set -d PAGE=System -d OUTER_TAB=tab_shutdown -d INNER_TAB=none https://[ReadyNASのIPアドレス]/get_handler

adminの後ろは自分の設定した管理者パスワードにする。IPアドレスは自分のReadyNASのIPアドレスにする。なお、これはホスト名でも可で、DHCPにしている場合はその方が便利。
このバッチファイルをCurlと同じフォルダに置き、ショートカットを張っておく。

両方のショートカットをスタートメニューに入れると、こんな感じ。アイコンはNetgearのサイトのfaviconを拝借。丁度形がDuoというか、Ultra 2と同じだし。

3.3. HDDトレイ

HDDの音については、それ単体で対処しないと仕方ない。初めに3.5インチの7K3000×2でしばらく稼働させてみたが、やはり2.5インチには比べるべくもないので、Duoに引き続いて2.5インチで行くことにした。

NetgearのHDDトレイにもQNAPのHDDトレイのように2.5インチ用のネジ穴があれば簡単なのだが、それはない。かつ、穴を開けるような気をなくさせる、ごついスチール製なので（穴の位置も合わない）、以前に目を付けていたIcy Dockのアダプターを使ってみる。ちなみに、Awowoから類似品が出ているが、NetgearのHDDトレイで必要になる底面のネジ穴が省かれているので（妙なところで手を抜く）、使えない。

Duoの旧型トレイにMB882SP-1S-1Bを（左側）、Ultra 2の新型トレイにMB982IP-1Sを（右側）取り付けた状態。

実用上はどちらでもいいのだが、金属製（たぶんスチール）のMB982IP-1Sはこれまたごつい作りで、動作もスムーズ。ただ、最初に使い始めたとき、中のHDDが認識されないことがあって焦った。原因は不明だが、端子をよく掃除した後は、それが効いたのかどうか分からないが問題はなくなった。

次にReadyNAS Remoteについて。

（Ultra 2とDuoの消費電力について計測した結果をこちらで）

AtomなReadyNASの速度を計る

noreply@blogger.com (EMO) — Sat, 05 Mar 2011 12:21:00 +0000

ReadyNAS Ultra 2の速度については、CPUのAtom 1.8GHzは現時点のAtom機としては最高クロックで、ソフトウェアRAIDもミラーリングだけだから負荷は低そうだし、同時に色々とやらせるのでもなければSingle coreもDual coreも変わらないだろうから、ReadyNASの中で速度に劣るということはないと思う。

そのUltra 2がどれぐらいの速度を示すのか。

（このエントリは一続きのエントリの2/5）

2.0. 環境

最初に、計測環境は以下のとおり。

使用するHDDの素の性能（PCに内蔵した場合、シーケンシャルアクセス）は以下のようなもの。
- Momentus 5400.5の320GBモデル: 65MB/s前後（関連エントリ）
- Travelstar 5K500.Bの500GBモデル: 85MB/s前後（関連エントリ）
- Deskstar 7K3000の2TBモデル: 160MB/s前後（関連エントリ）
ディスク構成は全て同じHDD×2によるX-RAIDまたはX-RAID2。Flex-RAIDにすれば何か変わるかもしれないが、ReadyNASのメリットを半分捨てるようなものだと思うので。
ネットワークは全てハブ（BuffaloのLSW-GT-5W）を介しての接続。前に見たとおり、このハブがボトルネックになることはないと思う。
Ultra 2のRAIDiatorは4.2.15。Duoの方は4.1.7で、メモリは1GBに換装してある。

2.1. ネットワーク速度

Windowsで普通にCIFSで共有したときの速度はどうか。

改めてDuoについて

先に、改めてReadyNAS Duoの速度について幾つか確認しておく。というのも、クライアントPCにWindows 7を使うようになって結構変化があったので。

第一にジャンボフレームについて、クライアントPCのThinkPad X61sのネットワークアダプター（Intel 82566MM Gigabit Network Connection）にはジャンボフレームの設定がないが、ReadyNAS側のジャンボフレームの設定を変えるとどうなるか。

まずX61s上のXP SP3からCrystalDiskMark（3.0.1）で計測したのが以下。HDDは7K2000と5400.5の状態。

7K3000ではジャンボフレームはほとんど関係ないが、5400.5ではジャンボフレームを有効にするとシーケンシャルアクセス、とくにライトが激しく落ちる。

次に同じくX61s上のWindows 7 64bitから。

傾向はXPと同じで、5400.5ではジャンボフレームを有効にすると速度が激しく落ちる。これは5K500.Bの状態でも全く同じだった。ということを踏まえて、以下では基本的に無効にしている。

ジャンボフレームが無効のときで比べると、Windows 7の方がシーケンシャルリードで10MB/sぐらい速い。

そこで第二に、Windows 7とXPでテストサイズを100MBと1000MBにした場合を、それぞれ7K3000と5400.5の状態で比べる。

全体的にシーケンシャルアクセスはWindows 7の方が速いことが分かる。

第三にボリューム使用量について、使用量によって速度に変化があるか。言い換えれば、ボリュームが埋まっていくと速度が遅くなったりするか。ということで、使用量を0%、33％、66%の三段階に調整した上で、Windows 7から7K3000と5K500.Bの状態で確認する。なお、5K500.Bは1年ぐらい常用していた状態で、細かいファイルが大量にあるので、フラグメンテーションが進んでいると思う。

使用量によってほとんど差は出なかった。

第四に、Windows 7からでテストサイズが1000MBの場合の、3種類のHDDの結果を並べると、

HDDによって見るべき差ははないことが分かる。

まとめると、

ReadyNAS側でジャンボフレームを有効にしても、（X61sからは）速度が上がらないばかりか落ちることがある。これはジャンボフレームの設定が合ってないときにはあり得ることだが。
Windows 7にしただけでXPより速くなる。
HDDによって、または、ボリューム使用量によって、速度はほとんど変わらない。したがって、こういうことを気にかけても意味はない。

Ultra 2の場合

さて、Ultra 2であるが、初っ端にいきなり問題にぶつかった。

デフォルトの状態ではリードの速度がまるで出ない。初期不良かと思ったが、調べてみると、デフォルトで有効になっているLowLatencyという機能をOFFにすることが有効だった（CIFSでのNAS→PCのコピーが異常に遅い）。以下はこのLowLatencyのON/OFFによる違い。

LowLatencyがOFFのときが正常だと思うので、以下は全てこの設定で行く。

気を取り直して、第一にジャンボフレームについて確認しておく。Windows 7から7K3000と5400.5の状態。

ジャンボフレームが有効でも5400.5はさほど変わらないが、7K3000の方はライトが落ちている。いずれにせよ、ジャンボフレームでいいことはないので、無効で行くことにする。

第二に、ボリューム使用量による差をDuoと同じように見てみる。7K3000の状態。

やはり違いは出ない。

第三に、3種類のHDDの結果を並べると、

よく分からないことになった。7K3000が一番速いのは順当なのでそれはいいとして、5400.5もリードではそれほど変わらない。これらに対して、5K500.Bは大きく落ちている。確かに5K500.Bは1年ぐらい使用歴があるが、それはその前に使っていた5400.5も同じだったりする。いずれにせよ、素の性能差ほどの違いがあるわけでも、素の性能が素直に出てくるわけでもない。

一応、Duoとの比較では、全体的にリードもさることながら、ライトが大きく上昇していることが分かる。

Iometer

別のやり方として、Netgearが性能の示標に使っているIometerではどうなるか。設定ファイルのiometer.icfはNetgearのもの（How to optimize the ReadyNAS performance）を利用し、テストサイズはUltra 2の製品紹介ページと同じ9GBにして計測してみた。

このIometerによる計測はこれまでやったことがなかったが、何これ？　という結果。確かにライトではUltra 2はDuoより10MB/sぐらい上がっているが、リードではDuoの時点でGbEの実用上の上限に近い100MB/sに達している。結果として、Ultra 2でさほど上がっているわけでもない。また、HDDによる差もあまり出てない。

性能の示標としては継続性が大事なのは分かるが、このIometerの計測方法ではGbEの上限に引っ掛かってしまって、本当の差が（あるとして）見えなくなっている可能性がある。これを今時の示標に使うのはどうかと思う。

Acronis True Image

また別のやり方として、 Acronis True Image 2010 Homeによるバックアップ/リカバリーの時間を計測してみた。USBメモリからブートし、X61s上のX25-Mに対して、ReadyNASへ直接バックアップ/ReadyNASから直接リカバリーを行う。対象はWindows 7のシステム兼ブートパーティションで、サイズは18.4GiB、使用領域は13.2GiB、ファイル数は73,836。

HDD	ReadyNASへのバックアップ		ReadyNASからのリカバリー
HDD	処理時間 (sec)	処理速度 (MB/s)	処理時間 (sec)	処理速度 (MB/s)
Ultra 2
7K3000	607	23.51	345	41.36
5400.5	600	23.78	349	40.89
Duo
7K3000	860	16.59	666	21.43
5400.5	863	16.54	655	21.79

それぞれの処理中にずっとReadyNASにアクセスしているわけではないが、処理時間ではUltra 2はDuoよりバックアップで約30%、リカバリーで約50%の短縮を見せている。一方、HDDによる差はほとんどない。

まとめ

ネットワーク速度は突き詰めると深いし、手間もかかるのでこれぐらいに留めるが、

Ultra 2でシーケンシャルリードはDuoから最大1.5倍（HDDによる）、ライトは2倍に上がった。
内蔵するHDDによる差はそれほどない。HDDの速度がそのままReadyNASの速度に反映されるわけでもないので、とくに気にする必要はないと思う。
ボリューム使用量による速度への影響はほとんどない。

2.2. USB3.0ポートの速度

NAS上のデータのバックアップもやり方は色々あるが、外付けHDDを繋げてさくさくコピーできれば、それが一番シンプルで楽だと思う。が、DuoのUSB2.0ポートは遅すぎて、バックアップに使うにはあまり実用的でなかった。

その点、Ultra 2は前面のUSBポートがUSB3.0になっていて、普通のPCでのUSB3.0ポートの例を見るとほぼHDDの素の速度で接続できるようなので、Ultra 2でもそういう速度が出ればと結構期待していた。

とりあえず、USB HDDとして、USB3.0対応のシンプルBOX2.5（CSS25U3BL）に5K500.Bの120GBモデルを入れ、X61sからNTFSのパーティションを作成の上、Ultra 2とDuoにそれぞれ接続し、X61sからCIFSで共有してCrystalDiskMarkで計測した。テストサイズは100MBと1000MBで、同時にReadyNAS側の「高速USBディスクの書込み」の設定の違いも確認してみる。

まず「高速USBディスクの書込み」を有効にすることによる速度向上は見られない。となれば、わざわざ有効にする必然性がなくなる。

問題は、Duoのライトの壊滅的な遅さは放っといて、Ultra 2のライトも微妙なこと。これぐらいの速度ならUSB2.0でも出ないことはない。

確認として、CSS25U3BLに7K3000を繋げた場合と、Green HouseのUSB3.0対応のGH-HDC3035AKに5K500.Bを入れた場合、それからUSB2.0のLaCie little diskの500GBモデルも計測してみる。テストサイズは1000MBで（100MBではLaCie little diskで異常に高い値が出る）、「高速USBディスクの書込み」は無効。

USB3.0の3つの場合は、どれも大体同じ結果が出ている。リードの方はさすがUSB2.0ではあり得ない速度だが、ライトの方はLaCie little diskとほとんど変わらない。

ただ、これはあくまでネットワークを介してX61sから見たときの話なので、Ultra 2との間だけならどうか、というのが次。

バックアップジョブ

ReadyNASではFrontviewから設定するバックアップジョブで直接ファイルの転送ができる。これを使ってReadyNAS内のフォルダとUSB HDDの間でファイルを転送するバックアップジョブを作成し、この所要時間をログで見てみる。

対象はAcronis True Imageのイメージファイル計31.5GiB。USB HDDはCSS25U3BLに5K500.Bを入れて、ファイルシステムをそれぞれExt3とNTFSにした場合で、比較のためLaCie little diskも加えた。

	速度(MB/s)
	CSS25U3BL + 5K500.B			LaCie litte disk
高速USBディスクの書込み	有効	無効
USB HDDのファイルシステム	Ext3		NTFS
Ultra 2 --> USB HDD	13.75	13.88	18.27	17.04
USB HDD --> Ultra 2	49.81	49.89	46.46	27.08

左側から順に行ったが、「高速USBディスクの書込み」はやはり意味がなかった。また、Ext3よりNTFSの方がリードは速いことが分かる。

USB HDDからUltra 2へのリードはUSB2.0を超えているが、Ultra 2からUSB HDDへのライトはLaCie little diskと大差なかった。つまり、X61sからCrystalDiskMarkで計ったときと傾向は同じ。

まとめ

結局、Ultra 2のUSB3.0ポートは、リードではともかく、ライトではUSB2.0並みというのが現段階での結論（Slow USB3 Backup - No faster than USB2）。勿論、それでもDuoのUSB2.0ポートよりは、はるかにましだが。

また、単純に速度の問題だけでなく、USB HDDの認識などにも変なところがあるので（Ultra 2におけるUSB3.0の動作）、根本的にRAIDiatorのUSB3.0関連部分がまだ熟成されてない様子。

いずれも今後のアップデートに期待。

[追記]

RAIDiatorを4.2.19にアップデートして、どうなったかを確認してみた。まずは速度。CSS25U3BLに5K500.Bを入れてX61sから見た場合で、以下のとおり。

とくに変化なし。いい加減速度については諦めが入ってきた。ちなみに、X61sのUSB2.0ポートに直接接続した場合は以下のとおり。

一応、Ultra 2経由でもUSB3.0で接続した方が、直接USB2.0で接続するよりかは速い。

次に認識などについて、4.2.15時点であった問題は以下の2点。

CSS25U3BLを挿した状態でUltra 2をブートすると、CSS25U3BLが認識されない。
バックアップボタンの長押しでCSS25U3BLがアンマウントされない。

このうち2.は4.2.16で解決していたが、1.はまだだった。それが4.2.19では解決していた。よって、この問題は終了。

なお、自分が気づいた若干の注意点。

アンマウントするときは、バックアップボタンをその上のLEDが消えるまで押し続けた方がよい。アンマウントの所要時間は一定していないので、中途半端に指を離すとUSB HDDへのバックアップ動作が始まってしまう。
USB HDDには「usb_hdd_6」など番号の付いたフォルダー名が割り当てられるが、この番号はHDDがフォーマットされると変わる（ファイルシステムなどが同じでも）。したがって、ネットワークドライブに割り当てている場合は、フォーマットの度に割り当て直す必要がある。

次に動作音について。

AtomなコンパクトReadyNASを見る

noreply@blogger.com (EMO) — Sat, 26 Feb 2011 14:38:00 +0000

何事も必要以上に大仰になるのが嫌いで、その意味でコンパクトなReadyNAS Duoというパッケージはよかったのだが、今となっては遅いNASで、自分のGbE環境のボトルネックになっていた。

速いNASが続々と登場してくる中で、どうしたものかと時々考えていたら、Duoの後継に当たるx86のAtom機であるReadyNAS Ultra 2が出ていたので、購入（ディスクレスのRNDU2000-100JPS）。Ultra 2（Single core）には上位版のUltra 2 Plus（Dual core）も存在するが、とくに重い使い方をするわけでもないので、Ultra 2でいいかなと。

（このエントリは一続きのエントリの1/5）

1.1. 外観

サイズ的にはDuo（左側）とUltra 2（右側）は変わらない。

現物を見るまで分からなかったのは、その色。Duoと並んだ写真がなかったのでよく分からなかったが、Duoがメタリックな黒なのに対して、Ultra 2はメタリックなダークグレー。光の具合によって見え方がかなり変わるので、写真に撮るには少し厄介。ちなみに、Ultra 2 Plusは黒のようなので、それとの差別化かもしれない。

色以外の違いは（後面を除く）、

側面の穴の位置が変わって一箇所になっている。
前面のUSBコネクタがUSB3.0になって中が青くなっている。

これが、Netgearの製品紹介ページやFrontviewでの画像もDuoの流用で、自分が見つけたまともな画像はnewegg（ReadyNAS Ultra 2, ReadyNAS Ultra 2 Plus）だけというのは何だかな。

1.2. 内部を見る

当然のごとく、側面を外して内部をしげしげと眺めてみる。

HDDベイの壁の向こう、右下のヒートシンクの下にCPUがある。このヒートシンクは40×40×15mmぐらいの大きさで、前方方向にはPCB上に突き出した部品もなく、開けている。PCBにAMIBIOSのシールが貼ってあるところは、やはりx86という感じ。

反対側にはDuoと同じくSO-DIMMソケットがある。PCBはファンを避けて切り欠いた形状になっている。

HDDベイは後面のファンまで、とても吹き抜けのよさそうな構造。ベイの上下のレールはDuoではプラスチックだったが、Ultra 2では全てスチール製。

ファンの直径は92mm。コンパクトな筐体の横幅一杯を利用して収められている。

ファンは3pinで接続。フレームはSATAコネクタの部分が切り欠かれていて、嵌まり具合を横から確認できる。

全体の印象として、

筐体は、前面のベゼルを除いて全てごついスチール製で、何でこんなにというぐらい頑丈。さらに3.5インチHDD×2を入れてその質量も加われば、殺人事件の凶器として十分以上かもしれない。
Duoでファンの騒音が問題になった反省か、Atomの発熱を考慮してか、筐体のサイズが許す最大直径のファンを積み、空流もよさげな構造になっている。その分、冷却、ひいては動作音の面で期待が持てる。

1.3. 部品も見る

Ultra 2は筐体内の見通しがいいので、個々の部品もチェック。

見えてないものも含めてまとめると、以下のとおり。

CPU	Intel	Atom D425 (1.8GHz, Single core)
チップセット	Intel	NM10 Express (CG82MN10)
Ethernetコントローラ	Marvell	Yukon 88E8057 PCI-E Gigabit Ethernet Controller
USB3.0ホストコントローラ	NEC	D720200F1
NAND Flash	Samsung	K9F1G08U0C-PCB0 (128MB)
NAND Flashコントローラ	Silicon Motion	SM321QF
ファン	Delta	AFB0912HH (92×25.4mm)
メモリ	ASint	SSY3128M8-EAE1D (DDR3-1066, 1GB)

CPUに関しては、dmesg.logでは以下のようになっている。

CPU0: Intel(R) Atom(TM) CPU D425   @ 1.80GHz stepping 0a
Booting Node   0, Processors  #1
Brought up 2 CPUs
Total of 2 processors activated (7199.96 BogoMIPS).

2 CPUsと出るのはHyper-Threadingのためだと思う。

USB3.0ホストコントローラはNECの定番。
Silicon MotionのNAND FlashコントローラはNAND Flashの真裏にある。このコントローラとNAND Flashを組み合わせたUSBメモリの例があるので、これはオンボードにUSBメモリが載っているとの同じだと思う。ちなみに、このコントローラはUltra 4のものと同じ（NETGEAR ReadyNAS Ultra 4 Reviewed - Internal Details, Features）。
ファンもUltra 4のものと同じ（ReadyNAS Ultra 4 92mm Fan spec）。Operating Voltage Rangeが「5.0 to 13.8VDC」のもので、回転数は最高（だと思う）で3300RPM。

以上のとおり、ごく標準的な部品で構成されている感じで、どれかの部品がハードウェア的にネックになって問題を引き寄せるということはなさそう。あくまでハードウェア的には。

続いて速度を確認する。

2TiB超え

noreply@blogger.com (EMO) — Thu, 13 Jan 2011 03:33:00 +0000

2TiBを超えるHDDを使うときの話。

（このエントリは一続きのエントリの2/2）

2.1. 素の状態

ThinkPad X61sのICH8-Mの内蔵ポート（AHCIモード）に3000を繋げた場合、Windows 7では32bit、64bitとも、そのまま普通にGPTディスクにして全容量を使える（ドライバはIntel Rapid Storage Technology 10.1.0.1008）。これは当然。

一方、素のXP SP3では、3000は746.51GiBと認識される（ドライバはIntel Matrix Storage Manager 8.8.0.1009、Intel Rapid Storage Technology 9.6.0.1024とも）。

（注）上に見えているのはOSのあるX25-M 80GB。

つまり、3000の容量は5,860,533,168（セクタ数）×512÷1024^3≒2794.52GiBなので、これから2TiB＝2048GiBを差し引いた容量となる。

ここから初期化して（MBRディスクになる）、この中にパーティションを作成して使うことも一応可能。この先頭の速度をCrystalDiskMarkで計ってみたらWindows 7でGPTディスクにしたときの先頭と同程度だったので、HDD内の位置としては先頭にある模様。

ちなみに、ドライバを新しい10.1.0.1008にしてみると、「ディスクの管理」で表示されなくなった。

デバイスマネージャでは表示されるものの、これでは使いようがない。

[追加]

環境を明記した。

2.2. Hitachi GPT Disk Manager

さて、3000の箱に入っていたクイックスタートガイドの紙には以下の説明がある。

この「Hitachi Edition GPT Loader」というツールはHGSTのサイトではなく、Paragonのサイトにあるが、名前が違っていて「Hitachi GPT Disk Manager」になっていた。

これをダウンロードして（Ver.1.0の英語版。URL違いで日本語版もある）XPにインストールしてみる。なお、HDDのチェックが入るので、3000が繋がってない状態ではインストールできない。

また、3000が繋がっていてもドライバが10.1.0.1008の状態では以下の表示が出る。

必要ないと言われても使えないのだが。ドライバを戻したらインストールできた。

インストール後は、HDDのGPTへの変換とパーティション作成に移る。

GPT Disk Managerを起動したときの初期画面。

「Convert Hard Disk to GPT」に進み、GPTにするHDDを選択。

どうでもいいことだが、3000の中に2047.9GiBと746.5GiBの空き領域があることになっている。MBRディスクっぽい表示だが、GPTディスクになってなければそう見なすらしい（実際にはセクタ0が空であっても）。

変換が済むと、今度は「Create and Format New Partition」に入る。

パーティションを作成するHDDと、その位置を指定（既存のパーティションがある場合、右下の矢印でどこに入れるかを変更できる）。

次にパーティションのサイズを指定。

フォーマット等も指定して実行すると、2794.5GiBのパーティションができる。

このパーティションはXPの「ディスクの管理」からも確認できる。

この状態で、Windows 7の「ディスクの管理」からも確認できる。

同じくDiskPartでも確認したところ。

この後、XP上のGPT Disk ManagerとWindows 7の「ディスクの管理」で色々とパーティションの作成、削除、縮小（GPT Disk Managerでは新しいパーティションを作成するときに既存のパーティションを縮小できる）/拡大を試してみたが、結果には互換性があった。つまり、GPT Disk ManagerがあればXPでもWindows 7とほぼ同じようにGPTディスクが扱える（とりあえず機能的には）といえる。

ただ、気づいたこともあった。

2.3. Microsoft予約パーティション

3000を空の状態に戻して（先頭を0fill）Windows 7の「ディスクの管理」で見たところ。容量は正しく2794.52GiBと出ている。

これをGPTで初期化すると、こうなる。

GPTディスクにしただけで容量が2794.39GiBに減っている。DiskPartで見てみると、「予約」という128MiBのパーティションができていた。これは「ディスクの管理」からは見えない。

これは何かと調べてみると、GPTディスク特有の「Microsoft予約パーティション」（MSR）というものらしい。

[参考]
Microsoft: WindowsとGPTに関するFAQ

ここで「ディスクの管理」からパーティションを作成すると、こうなる。

DiskPartから見ると、作成したパーティションはMSRの後ろにできている。

XPに戻って「ディスクの管理」で見ると、こうなっていた。

全容量は元のままだが、MSRは見えない。

上で見たとおり、GPT Disk ManagerでGPTにしたときにはMSRは作成されなかった。MSRがあってもなくてもとりあえず問題はないようだったが、MicrosoftはMSRを利用するつもりのようなので、Windows 7でも使う場合はGPTにするのはWindows 7からの方がいいかもしれない。

[追記]

その後、ダウンロードできるGPT Disk ManagerがVer.1.0.1に差し替わっていたので、XP SP3で試していたところ、以下のことに気づいた。

GPT Disk Managerで空のHDDをGPTディスクに変換した後、

一旦GPT Disk Managerを終了すると、MSRが作成される。
引き続き（GPT Disk Managerを終了させずに）パーティションを作成すると、MSRが作成されない。

これ以上はフォローしないが、GPT Disk Managerのバグのような気がする。

2.4. Paragon GPT Disk Manager

ちなみに、ParagonにはParagon GPT Loaderというツールがある。「アーリーアダプタープログラム」に参加してこれを使うことができるが、ダウンロードできるのは「Paragon GPT Disk Manager」だった。インストール後のフォルダを見ると「gpt_loader」というフォルダもあるので、「GPT Loader」＝「GPT Disk Manager」なのだろう。

で、この初期画面。

簡単に想像できるとおりで、一通り機能を使ってみたが、「Hitachi GPT Disk Manager」と同じものだった。初めからおよそ分かっていたことだが。

記録面を調べる

noreply@blogger.com (EMO) — Wed, 12 Jan 2011 01:42:00 +0000

HDDの速度から記録面数が分かる（かもしれない）割と簡単な方法がある。記録面数（＝ヘッド数）が分かれば、そこから記録面当たりの容量、プラッタ数も判別できる。

（このエントリは一続きのエントリの1/2）

1.1. 調べ方

方法はHD Tune Pro（4.0以降。15日間の試用版がある）でHDDを計るだけ。Readで先頭のごく一部を計るだけなので、HDDに特別な準備は要らないし、たいして時間もかからない。なお、フリー版のHD Tune（2.55）では不可。

HD Tune Proをインストールし、歯車のアイコンからOptionsを開いてBenchmark（HD Tuneの基本のシーケンシャルテスト）で「Full test」にする。この方が乱れの少ない結果を得られる。

普通はFull testにすると時間がかかるが、この方法ではごく一部しか計らないので、問題ない。
Benchmarkで「Short stroke」（HDDの先頭から指定した範囲だけで計測する機能）にチェックし、1GB（最小値）を指定する。なお、HD Tuneでの「gB」はSI接頭辞のGB（1GB＝1,000,000,000Bytes）の意。
これで計測すると、同じ高さ（速度）で一定の長さの水平線から成る組が繰り返し現れる。この組はShort strokeの範囲を1～10GBぐらいで変えながら計るとはっきりする。

この組の中の各水平線がHDD中の各記録面（の最外周ゾーンを分割したもの）を示すので、この数で記録面数が分かる。

ただし、これは記録面（の最外周ゾーンの線記録密度）に分かりやすい個体差があること、その記録面の速度（の変化）を正しく計測できることに依存するので、HDDや環境によってはうまく行かない。

この方法の背景については、過去のエントリ（記録面と速度の実際、プラッタ容量と速度の実際）参照。自分で考えたものだが、今のところ、否定する結果には行き当たってない。

1.2. Deskstar 7K3000の場合

HDD内部の細かいスペックをメーカーは公開しないようになってきているが、HGSTも新しいDeskstar 7K3000では、その前の7K2000までと違ってプラッタ数/ヘッド数をスペックに載せていない（Specificationもサイトに出てない）。

よって、これらは不明だが、店頭では書いてあったりする。それをとくに疑う理由はないが、自分で確かめられるものなら確かめてみたい。これまで記録面を調べてこなかった3.5インチHDDでもあるし。

対象は3TBと、2TB×2の3台。いずれもリテール版。

略称（便宜的に）	型番	容量 (GB)	製造年月	ファームウェア	シリアルナンバー	重量 (g)	組立工場
3000	HDS723030ALA640	3000.5	2010/12	3B0	YHG3T8XA	685	タイ
2000a	HDS723020BLA642	2000.3	2010/11	180	F303KA2D	664	中国
2000b	HDS723020BLA642	2000.3	2010/11	180	F304ALZD	663	中国

左から3000、2000a、2000b。

3000と2000は上下とも外観からして違う。というか、共通部分がない。

上蓋が違う。左下のヘッドスタックアッセンブリ部分のネジが3000は3本、2000は2本で、位置も違うので、たぶんヘッドスタックアッセンブリが違う。
ラベルにある12Vの消費電力が3000は850mA、2000は740mAなので、たぶんスピンドルモータが違う。
シャシーの形状が違う。プラッタの下の部分が3000の方が厚い。
PCBのパターンが全然違う。

ということで、3000と2000ではプラッタ数/ヘッド数が違うらしいことはこの時点で分かる。

リテール版の箱は共通のものだが、そこにある写真は7K3000発表時の資料に出ているもの（3TBだと思う）とは違う。

このプラッタ数は3で、ヘッドに繋がる配線（黄色の部分）が4段あるので、最上段は下向きに1つ、中間の2段は上下に2つずつ、最下段は上向きに1つヘッドが付いているとすれば、ヘッド数は6になる。まあ箱の写真を信じるかという問題もあるし、参考程度。

CrystalDiskInfo（3.10.0）で見たところ。とくに変わったところはない。キャッシュが32MBと表示されるのは、そういうものらしい。

[追記1]

その後、7K3000のOEM Specが公開された（2TB&1.5TBモデルだけ）。それによると、

2TBは3プラッタ6ヘッドなので、下記の結果と合致する。これはいいとして、
1.5GBの方も3プラッタだが、ヘッドは「5 or 6」と記載されている。つまり、5ヘッドなら記録面当たり300GBで、プラッタ当たり600GBとなり、6ヘッドなら記録面当たり250GBで、プラッタ当たり500GBとなる。当然、速度も変わり得るわけで、2.5インチHDDにおける3記録面問題と同じ、5記録面問題の勃発である。こういうときこそ、この方法が役に立つわけだが。

記録密度についても記載があるが、3TBも公開されたときに合わせて考えることにする。

[追記2]

3TBモデルのOEM Specificationも公開された。ただ、これはUltrastar A7K3000と一緒のもので、7K3000の3TBはA7K3000の3TBのDeskstar版のようである。つまり、名目上は同じ7K3000シリーズであっても、3TBモデルと、2TB&1.5TBモデルでは実質的に別シリーズだったというオチ。

ともあれ、3TBは5プラッタ10ヘッドなので、下記の結果と合致する。

一応、公称スペックをまとめると以下のようになる。

モデル	ヘッド数	記録面当たり容量 (GB)	Max Data transfer rate (Mbps)	Typ Sustained transfer rate (MB/s)	Recording density - max (Kbpi)	Track density (Ktpi)	Areal density - max (Gbits/in²)
3TB	10	300	1631	162	1445	255	369
2TB	6	333.3	1656	162	1443	285	411
1.5TB	5 or 6	300 or 250	1433	140	1249	247	308

内部写真を見る限り3TBも2GB&1.5TBもプラッタ中央の抑え金のサイズは変わらないようなので、データビットに使える面積は同じだと思う。その上で記録密度を見ると、3TBと2TBは線記録密度（最大）がほぼ同じで、容量の差は下記で推測したとおりトラック密度（最大、だと思う）によることが分かる。

したがって、公称スペック上の最大値としては3TBと2TBの速度はほぼ同じで、後は個体による差、ということになる。

一方、1.5TBのスペックは5ヘッドで記録面当たり300GBの場合のものだと思うが、それにしても同じ記録面当たり容量の3TBよりかなり低い。公称スペックでこれなので、6ヘッドの可能性があることも考えると、同じプラッタ数で500GB違いの2TBと比べて積極的に選択する理由はないように思う。

1.3. 記録面の判別

計測に使ったのはThinkPad X61s。そのICH8-Mの内蔵ポートに対象のHDDを接続し（これと同じ）、Windows 7 64bit上のHD Tune Pro（4.60）で計測した。AHCIのドライバはIntel Rapid Storage Technology 10.1.0.1008。パーティションはない状態

まず3000は、1GBでは組が入りきらず、3GBで繰り返しがはっきりした。組の前半は変化が少ないが、後半に大きく動いて、分かりやすくてラッキー。3GBと6GBでのグラフを抽出したのが以下（便宜的に各水平線にアルファベットを振った）。

面の数は10で、組の長さは約1.5GB。したがって、10記録面、5プラッタということで、プラッタ当たり容量は600GBということになる。

次に2000bも分かりやすい。このグラフが以下。

面の数は6で、組の長さは約1GB。したがって、6記録面、3プラッタということで、プラッタ当たり容量は667GB。

問題なのは2000a。3つの高さの水平線が繰り返すので、3の倍数ということは確定だが、各水平線の長さが飛び抜けて長い。同じ高さでも長さが交互に入れ替わっているように見えるもの（以下のCとF）があるので、別の面と見なせば以下のようになる。

面の数は6で、組の長さは約2.05GB。各面の長さは3000と2000bの倍以上になる。

これらの2GBでのグラフをまとめてみた。

（注）速度はSI単位系のMB/sに換算した。以下同じ。

意外なことに速度は完全にバラバラではなく、ばらけているなりに揃っている。3000は2000よりプラッタ当たり容量が少ない分、全体的に低めなのかと思ったが、そうでもないらしい。容量の調整はトラック密度の方でやるということかもしれない（2.5インチの5K500.Bは公称スペック上はそうだった）。
速度は最高の面で166MB/s程度、最低の面で146MB/s程度なので、幅は20MB/s程度で、約12％ある。
この中で160MB/s程度の面を普通とすると、2000aは高い面が多く、2000bは高い面があるが低い面もある、3000は普通が多いといったところ。

念のため、この中で変化の大きい2000bについて、各面に収まるようパーティションを作成し（先頭から番号を振った）、CrystalDiskMark（3.0.1）で計ってみた。テストサイズはパーティションの容量の都合上、100MB。

この結果をHD Tune Proのグラフと重ねたところ。

速度の変化は一致しているが、CrystalDiskMarkの方が幅は大きい。幅は28MB/s程度で、約16%。

以上で、記録面（の最外周ゾーン）については大体分かった。

1.4. 他の指標との関係

記録面は分かったとして、これが他の指標ではどう出るか。ということで、CrystalDiskMarkを組がほぼ収まる2GBのテストサイズで計ってみた。

2000aと2000bはほぼ同じで、これは上で見た結果と合致する。3000がそれに次ぐことも合致するが、差はやはりHD Tune Proより大きい。

次にHD Tune Proで全体を計った結果。Full testと、Partial testを5段階中の5と、同じく4（デフォルト設定）にした状態。

Partial testのギザギザは、記録面の変化が大きいほど激しくなる傾向があるのが見て取れる。

このFull testの結果をまとめると、まず割合ベースでは以下のようになる。

波形は完全にならされているが、先頭部分が2000a、2000b、3000の順になっているのは、それぞれが持つ記録面の速度が平均化されればこうなるだろうな、という感じ。かつ、その順位がゾーンを通じて大体変わってないことも分かる。

次に容量ベース。

500GBぐらいで2000と3000の順位が逆転する。当然だが、2TBまでの平均でいえば3000が一番高くなる。

さらにPartial testで、100GBから1GBずつ計測する範囲を広げながら計ってみた。

この3000のグラフを抽出したのが以下。

大きな波が出ているのは折り返し雑音のようなものだと思う。計測する範囲が広がるにつれてサンプリング位置が微妙にずれていくが、その小さな違いで大きな変化が現れる。ということを見るに、Partial testのギザギザは、やはりサンプリング位置にどの記録面が当たるかに左右されているように思う。

最後にランダムテストの結果。範囲は10GB、100GB、全容量の順。

10GBと全容量では、3000がわずかに優位だが、ほとんど同じ。

100GBでは、2000a、2000bともに30GBぐらいの位置での値が足を引っ張っているのが分かる。そこで範囲を40GBにしてみたのが以下。

代替セクタでもあるのかと思ったが、2つとも28～32GBの間でランダムに遅くなる現象が起きている。この程度の範囲ならランダムアクセスでもヘッドが動く幅はごく小さいはずだが（肉眼では見えないぐらい）、アームが動く音もする。謎だが、HD Tuneのアクセス方法とHDDの機構との間で何か嵌ったのかもしれない。

1.5. まとめ

HD Tune ProのShort strokeを使って記録面を調べる方法が3.5インチHDDでも確認された、と考えてよいと思う。
HDDの（平均化された）速度は、どういう速度の記録面で構成されているかによる。同じモデルなのに速度が違うというときは（それ自体は極めて普通だが）、記録面を調べると何か分かるかもしれない。
組の長さが1GBを優に超えるHDDがあることが分かったので、ベンチマークの際には対象範囲を考慮する必要があるかもしれない。

次に、2TiBを超えるHDDを使うときの問題について少し。

Nanoな無線LAN

noreply@blogger.com (EMO) — Tue, 21 Dec 2010 12:36:00 +0000

ThinkPad X6xの右パームレストの熱問題にずっと付き合ってきたが、ようやく最終手段に訴えることにした。つまり、内蔵無線LANカードの撤去である。

1. 代替手段

熱問題に対して内蔵無線LANカードの撤去はすぐに思い付くことだが、その代替手段をどうするかで二の足を踏んでいた。

PCカード型の無線LANカードでは、今度は左パームレストに熱問題が発生しかねない。出っ張る部分が邪魔だし（かつては出っ張らない製品も存在したが、規格が古い）、持ち運び時に危なっかしい。かといって、運ぶ度に抜き挿しするのも面倒。
USB接続の無線LANアダプターでは、出っ張りが邪魔だし、（以下同文）。

が、最近はUSB接続でも非常に小さい製品が出てきている。その一つがPlanexのGW-USValue-EZで、常用しているLogicoolのNanoレシーバーと同程度なら許せるかと思って買ってみた。

右側がGW-USValue-EZ。

サイズに関しては期待以上で、Nanoレシーバーより短い。X61sに挿した状態で以下。

挿した状態でもNanoレシーバーより出っ張りは短い（厚みは少しあるが）。ということで、サイズは合格点。

2. 設定

Windows 7の場合

X61s上の64bit版、X60s上の32bit版の両方で、Access Connections（5.72）から内蔵無線LANと同じようにプロファイルの設定ができ、ネットワークへの接続/切断、電源のオン/オフも可能。有線LANに繋がった状態からLANケーブルを抜けばAccess Connectionsの機能で自動的に電源オンになって無線LANに繋がり、LANケーブルを挿せば自動的に電源オフになる。無問題。

Windows XP SP3の場合

Access Connections（5.72）内だけでプロファイルの設定はできず、暗号化はOSの機能で設定することになるが、設定ができればAccess Connectionsからネットワークへの接続/切断は可能。ただし、電源のオン/オフはできない。

Planexのユーティリティには電源のオン/オフの機能はないが、内蔵チップはドライバーのファイルを見るとRealtekのRTL8192CUらしいので、Realtekのユーティリティを使うと、電源のオン/オフと同時にネットワークへの接続/切断ができた。

デバイスマネージャで「詳細」を見ると、VID（ベンダーID）とPID（プロダクトID）が分かる。
RealtekのサイトからRTL8192CU用のドライバーとユーティリティのセットをダウンロードし、展開する。このインストーラの設定ファイルであるIsConfig.iniを開き、

[92CU_Utility]
TitleName=REALTEK 11n USB Wireless LAN Software
ProductGUID=9C049499-055C-4a0c-A916-1D12314F45EB
DeviceID=VID_0BDA&PID_8192;VID_0BDA&PID_8176;VID_0BDA&PID_8177;VID_0BDA&PID_8178;VID_0BDA&PID_817D;

のDeviceIDの部分に1.で見たVIDとPIDを追加する。

[92CU_Utility]
TitleName=REALTEK 11n USB Wireless LAN Software
ProductGUID=9C049499-055C-4a0c-A916-1D12314F45EB
DeviceID=VID_2019&PID_ED17;VID_0BDA&PID_8192;VID_0BDA&PID_8176;VID_0BDA&PID_8177;VID_0BDA&PID_8178;VID_0BDA&PID_817D;

これでインストール。
インストールされた「REALTEK 11n USB Wireless LAN Utility」を起動し、「プロファイル」でネットワークの暗号化などを設定する。

これで、タスクトレイからこのユーティリティを呼び出し、「無線オフ」のチェックを外せば電源オンになって無線LANに繋がり、チェックを入れれば電源オフになって無線LANから切ることができるようになる。

正直、XPでのやり方はスマートではないが、Windows 7を主用しつつ、時々XPを使うぐらいなら、これで十分。

[追記]

実際に載っているチップはRTL8188CUSとのこと。

3. 結果

内蔵無線LANカードを（ついでに一度も使ったことのない内蔵モデムカードも）撤去したが、熱はまだ感じる。これ以上はどうしようもないが。

GW-USValue-EZに機能的な不満はないが、見過ごせない問題もある。それは、

青色LEDが眩しく点滅してうるさい！

外装のプラスチック自体が半透明になっているので、LEDの光が盛大に目に入ってくる。LEDが青色だと格好よく見えたのも昔のことで、その無駄に強い光に辟易するようになって久しいが、これは光の通る面積が広いだけに最悪。周辺機器ベンダーには眩しすぎる青色LEDはもう止めてほしい。

とりあえず黒ビニールテープで軍艦巻きにして対処した。

[追記]

ビニールテープも何なので、外側をエナメル塗料のブラックで塗ってみた。が、遮光力が低い/塗膜が弱くて剥げるという問題で断念。仕方ないので、内側からの対策を考えてみた。

USBコネクタの中を覗くと、PCBとアンテナが見える。構造としては、PCB上のパターンが直接USBの接点になっていて、そのPCBに外側の金属を嵌め、端を半透明のプラスチックで覆ったという形。問題のLEDもPCB上にある。

PCBの上には空間があるので、ここに何か入れてLEDの光を遮ればいいわけだが、白いプラ板で試したら光が透けて駄目だった。ということで、色付きの適当な材料を探したところ、出てきたのがX40の交換したキーボードベゼル。黒いプラスチックで丁度良い。

この薄い部分を約11×4mmの寸法に切り出し、当たりを調整しながら差し込んで固定。

出来映えはこんな感じ。

光は上に出てこなくなった。動作状態を確認したいときは横から見るということで。