HD Tuneのぎざぎざの理由

HD TuneのBenchmarkがAdaptive FormattingのHDDでぎざぎざを描く理由について、記録面の波形によるものと推測してきたが、その結論。

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

• HD Tuneのぎざぎざの理由
• HD Tuneのぎざぎざの評価

1.1. HD TuneのBenchmarkの計測方法

他のソフトの動作を外から分析するのはあまり行儀がいいとは言えない気がするが、これを確認しないと先に進めないので、HD Tune Pro（4.01）がBenchmarkを実行中にどうアクセスしているかをProcess Monitorで見てみた。対象はTravelstar 7K1000で容量は1TB。設定はPartial testで5段階中のAccurate側の4段目（デフォルト）、Block sizeは1MiBに設定してリード。

これは開始時で、この後ずっとReadFile（Win32でリードするAPI）が続いていくが、このDetailにリードした位置とサイズが出ている。Offsetが先頭からの距離、すなわち位置で、Lengthがサイズ。単位はByte。

初めに位置0でサイズが512Byte、すなわち1セクタのリードをしている。設定と違うので何かと思ったが、計測位置をジャンプさせる度に初めは同様に512Byteのリードをしているので、これはたぶんHDDをシークさせるためだけのリードで、速度の計算には入れてないのだろうと思う。

これに続いて1048576Byte＝1MiBのリードが、隙間なくシーケンシャルに行われている。

結果をまとめると、少し戸惑わせることが分かった。

1. 計測したサイズ（1MiB×リード回数）は計22250MiBで、容量の2.3%。まあそんなものか。
2. 計測点の数は200で、各計測点の開始位置は容量を単純に200等分したもの（0、5GB、10GB……）。これはログから予想できたこと。
3. 各計測点のサイズは一定ではない。……何コレ。

速度を計算するには比が分かればいいのであって、一定のサイズにする必然性はないが、計測条件はなるべく揃えるものじゃないかと思いつつ眺めていたら、気づいた。各計測点のサイズは、その計測点における速度に比例している。

各計測点における速度とテストサイズの関係をまとめたのが以下。速度はMB/sに、テストサイズはMBに、位置は都合でGiBに換算してある。

ほぼ完全に一致している。意図はよく分からないが、たぶん計測しながら速度を見て後何回リードするか決めているのか、予め決めた時間内だけリードを繰り返すようにしているのだと思う。

ちなみに、X25-M G2を5段階中の5段目で計測したときはテストサイズは381MiBで一定だったので、上限はあるっぽい。

1.2. 計測点をDisk Gazerと比較

とにかくHD Tune Proがリードした位置とサイズは分かったので、先頭から40個の計測点について、その位置の波形をDisk Gazerで計測したものと比較してみる。

左側がHD Tune Proのログから抜き出したもので、赤点が各計測点。右側のDisk Gazerのチャートで計測点に当たる部分を赤枠で囲ってある（数が多いので、スライドさせながら見てもらうといいと思う）。

一目瞭然だが、HD Tune Proの値は計測点が波形のどの部分にかかっているかで決定されているのが分かる。荒れた海を走る船のごとく、高い面に乗れば高く、低い面に落ちれば低く、面の間にまたがったときはその割合に応じて、上下している。

これがHD Tuneのぎざぎざの理由、ということになる。

各計測点における値は、その位置とサイズで得られた値として間違ってはいないが、それらを結んだチャートの形は、そのとおりに実際の速度が変動しているわけではないという意味で、偽のものと言えると思う。

次に、これをどう評価するかについて。