2010/02/28

記録面と速度の実際(応用)

基本的な性質は分かったので、応用について。

(このエントリは一続きのエントリの5/5)

5.1. 線記録密度を計算する


記録面の線記録密度は、原理的に、条件が揃えばシーケンシャルリードの速度から計算できる。その条件として以下のようなものがある。
  1. 回転数が分かっていること
  2. 物理的なトラック長が分かっていること
  3. 速度にリードキャッシュの影響がないこと
  4. 速度にブロックサイズなどの影響がないこと
  5. 速度に他の制約要因の影響がないこと(PC本体の能力、HDDのコントローラの能力など)
  6. トラック間の移動時間を含まない速度が計測できること
  7. 記録面が複数ある場合、平均化されない個々の記録面の速度を計測できること
このうち1.は公称スペックが概ね信用できるし、2.は既に分かっている。3.と4.と5.は計測結果から一応検討できる。問題は6.と7.で、この目途が立たないので追求を諦めていた。

それが、6.はHddRpmEstの結果から分かるし、7.は従来のシリンダの理解に根ざした問題だったので、それが当てはまらないとすれば、そもそも問題ではなかったことになる。

そこで3.と4.と5.について改めて検討すると、3.のリードキャッシュは、HD Tune Proでは影響している気配はないので、ないと見なしてよいと思う。

4.のブロックサイズは、5K500.B-500aの先頭1GBを設定を変えながら計測すると、以下のようになる。
Travelstar 5K500.B-500 a: HD Tune Pro (Seq. Read, 1GB, Full) compiled

64KB以上ではほとんど変わらないので、64KBでの値を使えると思う。

5.の他の制約要因については、原理的に、その影響がない理想的な状態では速度はトラック当たり容量に比例するので、線記録密度の平均が各ゾーンで一定と仮定すれば(ゾーン内での高低は措くとして)、速度はトラック半径に比例する。この比例度合いを見ることでその影響を推し量れると思う。

これを5K500.Bで計算すると以下のようになる。

トラック半径(注)速度(平均)
最外周
(mm)
最内周
(mm)
比率最外周
(MB/s)
最内周
(MB/s)
比率
5K500.B-500a30.6514.300.46789.7042.20 0.470
5K500.B-500b81.2940.57 0.499
5K500.B-12083.1538.32 0.461
(注)正確にはゾーン内の外周か内周かで揃えるべきだが、どちらも片方しか分からない。

比率は意外と離れてないので、大きな影響はなさそうである。

条件は一応クリアしたとして、5K500.Bの最外周トラックについて計算してみる。計算式は5K500.B-120の場合で以下のとおり。

[{83.15(MB/sec)×1.154(HddRpmEstにいうバースト転送速度と維持転送速度の比率)}(トラック間の移動時間を含まない速度)×0.0111(sec)(5400RPMでのトラック一周時間)](トラック当たり容量)÷{30.65(mm)(トラック半径)×2×π}(トラック長)×1,000,000(Byteへ換算)×8(Bitへ換算)×25.4(インチへ換算)÷1,000(Kへ換算)=1125.3(KBPI)

記録面速度
(平均)
(MB/s)
トラック当たり
容量
(MB)
線記録密度
(KBPI)
公称線記録密度
(最大、1356KBPI)
との比率
5K500.B-500aA B91.251.1731237.991.3%
C D87.911.1301192.788.0%
5K500.B-500bA84.381.0841144.184.4%
B83.071.0671126.483.1%
C74.880.9621015.374.9%
D82.941.0661124.582.9%
5K500.B-120
83.151.0661125.383.0%

実際には、線記録密度は同じゾーン内でも内周の方が高く(5K320のSpecificationの例で計算したときには最大で50KBPI強の差があった)、PC本体の能力が高ければ速度はもっと出ると思うので、少なくともこれぐらいはあるという数字と考えた方がよい。

5.2. ベンチマークに対する影響


容易に想像できることだが、ベンチマークで計測する領域と高低の記録面の位置がはまった場合、小さな位置の違いで割と大きな速度差が出る。

記録面間の差が大きい5400.5-320aの場合、(作為的ではあるが)先頭から124MBずつ3つのパーティションを作成してCrystalDiskMarkとHD Tune ProのFile Benchmarkで計測すると、以下のようになる。
Momentus 5400.5-320 a: CrystalDiskMarkMomentus 5400.5-320 a: HD Tune Pro File Benchmark
(注)File Benchmarkのブロックサイズの表示は下が隠れてしまっている。4.0でウインドウサイズが可変になった関係かもしれない。

シーケンシャルリードについてHD Tune ProのBenchmarkのグラフと重ねて整理したのが以下。
Momentus 5400.5-320 a: HD Tune Pro & CrystalDiskMark (Seq. Read)

この問題を意識して避けるには、計測するサイズを記録面の組当たり容量(HDDによって変わってくるが、5K500.B-500なら400MB、5400.5-320なら200MB程度)を超えるものにする必要がある。これはピークをとる場合には最も速度の出る記録面を外さないために、平均をとる場合には元の値を正しく集めるために有用。

また、ベンチマークにおけるバラツキの理由の一部はこの問題で説明されると思う。OSや他のソフトの挙動、ファイルシステムの影響、他のデバイスの割込などを気にしていたら、肝心のHDDの速度に凹凸があったということで。

5.3. HD Tuneのグラフに対する影響


HD TuneのBenchmarkでは、Partial testが初期設定だが(3.5まではこれしかない)、この設定ではHDDによってはグラフに大きなぎざぎざが出ることがある。これが何故なのか気になっていたが、4.0のFull testではほとんど出なくなるので、Partial testに特有の問題らしい。

5K500.Bの3台について、Partial testを5段階中の4段(初期設定)と5段で計測した結果が以下になる。
Travelstar 5K500.B-120, 500 a&b: HD Tune Pro (Seq. Read, 64KB, Partial) compiled

まず単一の記録面の5K500.B-120では全く上下動が出ていない。これは前に5K320-80を2台調べたときも同じ結果だった。

その上で、5K500.B-500aと500bの間では、(500aの100GB付近の乱れは措くとして)500bの方が振れ幅がやや大きいのが分かる。これは、500aのゾーン0の記録面間の高低差(4MB強)より500bの高低差(10MB弱)の方が大きいことと符合する。

同様に5400.5の2台について、Partial testを5段階中の4段と5段で計測した結果が以下。
Momentus 5400.5-320 a&b: HD Tune Pro (Seq. Read, 64KB, Partial) compiled

とくに4段の方で顕著だが、5400.5-320aの方が320bより振れ幅が大きい。これも320aのゾーン0の記録面間の高低差(12MB強)の方が320bの高低差(6MB強)より大きいことと符合する。

まとめると、
  • グラフに激しい上下動が出るのは記録面が複数あるHDDの場合。
  • 記録面間の高低差が大きい方がグラフの振れ幅も大きい。
これから推測すると、Partial testの計測位置になった部分がたまたま高低の記録面に当たり、その値が平均化されずに出てきた(Full testでは計測位置が多いので平均化されると考えて)ことがぎざぎざの正体、少なくともその一部ではないかと思う。であれば、あのぎざぎざは計測上のノイズ的なものではなく、正確に計測した結果だったことになる。

5.4. 3記録面問題


あるシリーズの最大容量のモデル(2プラッタ4ヘッド)とその半分の容量のモデル(1プラッタ2ヘッド)の間には、3ヘッドと4ヘッドの両方があり得るモデルが存在したりする。5K500.Bでは320GBモデルがそうで(Specificationに「3/4」と表記)、5400.5では250GBモデルがそうである(Product Manualに「4 or 3」と表記)。5K320の250GBモデルのように、公称スペックでは3ヘッドでも実際には4ヘッドの個体があることもある。

こういうモデルにまつわる問題として、
  • 外からはヘッド数が判別できない。1プラッタか2プラッタかは重量で判別できるし、1プラッタ1ヘッドの場合は容量的にそれしかないことが多いが、3ヘッドか4ヘッドかは手掛かりがない。

  • ヘッド数により大きな性能差が出る可能性がある。5K500.Bの全ての容量別モデルを見ると、
    全容量
    (GB)
    ヘッド
    記録面当たり
    必要容量(GB)
    公称線記録密度
    (最大)(KBPI)
    50041251356
    4004100
    320480
    3107
    2502125
    1602801305
    12011201356
    80(注)1801305
    (注)80GBモデルは初期のSpecificationにはあったが、後に消えている。

    公称スペックの線記録密度(最大)は160GBモデルと80GBモデルが落ちる以外は全部同じだが、320GBモデルの場合、3ヘッドであればまだしも、4ヘッドであれば記録面当たり必要容量がこれらの落ちるモデルと同じになるので、性能もこれら並になっている可能性がある。
したがって、こういうモデルでは外から判別できないヘッド数(=記録面数)によって大きな性能差があり得る、という福引きにも似たHDD選びの中でもその度合いが高いという問題がある。これを個人的に3記録面問題と呼んでいる。

それが、MK3263GSXのように記録面間にそれと分かる速度差があれば、速度だけから記録面数を判別できる可能性がある。

5.5. まとめ

12 HDDs

HDDのベンチマークにそれなりの労力を費やしてきた人間として、少し鬱である。なるべく正確な結果を得ようとした努力のかなりが見当違いのものだったと分かった。
  • 現在のHDD(複数の記録面を持つもの)には、速度が違う一定の容量の領域から成る組があり、この組の繰り返しでHDDは構成されている。組の中の領域は、ある程度の容量を超えると、単独あるいは一斉のタイミングで、段階的に速度を落としていく。

  • この現象は従来のシリンダの理解では説明できない。対して、「HDD中のアドレスはトラックごとに他の記録面のトラックに移動するのではなく、同じ記録面のトラックへの移動を一定の範囲で繰り返してから、他の記録面に移動する」という仮説に従い、組の中の領域は各記録面であり、これがゾーンを変えるときに速度が落ちると考えれば、この現象を説明できる。

  • これは同じゾーンに速度が違う記録面が存在することを意味するので、HGST以外のSeagate、東芝、Western Digitalの各メーカーもAdaptive Formattingか、類似の方法をとっていることになる。

  • この仮説に従えば、同一円筒上にある複数のトラックから成るシリンダというものは既に存在しないか、使われておらず、いずれにせよ意味を失っている。

    この現象は2002年にAdaptive Formattingが適用されたHDDが出現した頃から存在した。つまり、その頃から従来のシリンダの理解は当てはまらなくなっていたことになる。シリンダは消えた。というより、とっくに遠くへ消え去った後だった。

  • この仮説の成否とは別にして、HDDのベンチマーク方法を考えるときにはこの現象を意識した方がいいと思う。これまで信じられてきたように、HDDの先頭が文字通り一番速度の出る領域とは限らないので。

    ピークをとるにせよ、平均をとるにせよ、組の中の全ての領域をカバーした方が正確なので、計測するサイズは組当たりの容量を超えるものにした方がいい。この容量は実際のHDDによるが、HGSTの2.5インチHDD(2プラッタ4ヘッド)では400MB程度。HD Tune Proには試用版があるので、それを使えば簡単に確認できる。

  • 記録面間に特徴的な速度差があれば、外から計測した速度だけから記録面数、さらには記録面当たり容量を判別できる可能性がある。
プラッタ数の多い大容量の3.5インチHDDではどうなのかは、後の課題。

記録面と速度の実際(先頭以外)

速度に戻って、HDDの先頭以外の部分についても見てみる。

(このエントリは一続きのエントリの4/5)

4.1. 方法


HD Tune Proのログを見ると、先頭1GBを計測したとき、指定したブロックサイズ(標準は64KB)で計測していった値から5MB単位で平均をとって表示、記録するようである。この単位は自動的に計測する範囲の1/200になるようで、計測する範囲が広がるにつれて平均化の単位も大きくなる。

問題の波形(領域ごとの速度差)は、平均化の単位が大きくなるにつれて形が鈍っていき、そのうち判別できなくなるので、先頭以外の波形を見るにはHD Tune Pro以外の方法に頼る必要がある。

色々試した結果、以下の2つの方法に行き着いた。

Iometerを使う


HD Tune Proの計測方法を模して、64KBのリクエストサイズのシーケンシャルリードのアクセスパターンで、計測サイズを5MBとし、計測開始位置を5MBずつずらしながら計測する。計測時間は各4秒。マクロで実行し、結果はログを集計して見る。

問題として、HDDと計測位置によっては、おかしな値が出ることがある。リードキャッシュの影響かもしれない(Process Monitorで見る限り、Iometer配下のDynamoもNon-cachedでリードしているようだが)。使ったのは安定版の2006.07.27だが、開発中のバージョンでもそれぞれにおかしかった。

DiskSpeed32を使う


DiskSpeed32は、シーケンシャルリードを計測し、CHSアドレスにいうシリンダ単位(大抵7.7MBか8.2MB)でまとめて記録するツール。リクエストサイズは約32KB。Full testではHDDの先頭から全セクターを計測していく。

以下は5K500.B-500bを計測した例。
Travelstar 5K500.B-500 b: DiskSpeed32

グラフは横方向に圧縮された形になる(計測位置が非常に多いので)。グラフのサイズは変えられるが、一部を拡大したりはできないので、出力したログを加工して見ることになる。

問題として、計測結果がかなり鈍るので(値自体は概ね変なものではないが)、大まかな形しか分からない。説明によれば代替セクターになっている部分も分かるというので(中頃の2つの縦線は試行によっても変わらないので、それらしい)、細かい変化も鋭敏に捉えるはずではあるが。

4.2. 5K500.B-500の場合


HD Tune Proで全体を見ると、5K500.B-500bのグラフは、ゾーンが階段状にはっきり出る5K500.B-120よりなだらかな形になっている。
Travelstar 5K500.B-120, 500 b: HD Tune Pro  (Seq. Read, 64KB, Full) compiled

とくに目星もないので、Iometerで先頭から100GBずつの位置を計測してみた。300GB以降は明らかにおかしかったので、先頭、100GB、200GBの位置における結果を作図すると、以下のようになる。
Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)

先頭1GBの波形はHD Tune Proの結果と大体一致する。波形自体は100GB、200GBの位置では微妙に形が変わっている。これを確認するため、DiskSpeed32の同じ位置の結果を作図すると、以下のようになる。
Travelstar 5K500.B-500 b: DiskSpeed32Travelstar 5K500.B-500 b: DiskSpeed32Travelstar 5K500.B-500 b: DiskSpeed32

上下動が激しいが、大体の形はIometerと一致しているので、計測上の問題ではなさそうである。

何が起きているのか、波形が変わる場所を探してみる。適当に見当を付けてIometerを走らせると、18GB付近で以下が見つかった。
Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)

記録面の高さが1つだけ変わっている。各記録面が分かりやすいようHDDの先頭から出現した順にA、B、C、Dの名前を付けると(右下にゾーン番号)、以下のようになる。
Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)

この中のA面は18.2GB手前でB面に交代した後、18.4GB過ぎでD面を引き継いだときには高さが変わっている。これはA面のゾーンがここで一段下がったと考えれば理解できる。

同じように他の面についても、それぞれ高さが下がる場所が見つかった。D面は25GB付近、 B面は27GB付近、C面に至っては44GB付近で。
Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)Travelstar 5K500.B-500 b: Iometer (Seq. Read, 64KB)

こういう変化を繰り返すことで、波形が変化していくらしい。100GB付近の波形になるまでは後一回りはゾーンが下がっているように見える。

折角なので、各記録面のゾーン0の容量を計算してみた。これを繰り返していけば個々の記録面に分解したグラフを作成することも不可能ではない。
記録面ゾーン0の容量(GB)
A4.6
B6.8
C11.1
D6.3

予想はしていたが、以下のことが分かる。
  • それぞれ速度も容量も違う記録面を組み合わせて使っている。
  • 各記録面でバラバラにゾーンが変わっていく結果、位置によって波形が変わり、全体として明確なゾーンの変わり目ができないので、グラフになだらかな部分ができるらしい。
次に5K500.B-500aについて、Iometerによる先頭、100GB、200GBの位置における結果は以下のとおり。
Travelstar 5K500.B-500 a: Iometer (Seq. Read, 64KB)Travelstar 5K500.B-500 a: Iometer (Seq. Read, 64KB)Travelstar 5K500.B-500 a: Iometer (Seq. Read, 64KB)

2つの面の関係は変わらないが、差が変化している。DiskSpeed32ではこんなもの。
Travelstar 5K500.B-500 a: DiskSpeed32Travelstar 5K500.B-500 a: DiskSpeed32Travelstar 5K500.B-500 a: DiskSpeed32

波があるのは分かるが、鈍り過ぎていてあまり参考にならない。

Iometerでゾーンの変わり目を探してみると、16GB付近と36GB付近にあった。ただし、どの位置でも2つの高さの面しか出てこない。
Travelstar 5K500.B-500 a: Iometer (Seq. Read, 64KB)Travelstar 5K500.B-500 a: Iometer (Seq. Read, 64KB)

この1つの水平面が、1つの長い記録面なのか、2つの同じ高さの記録面が並んでいるのか判断できる材料はないが、組の長さは5K500.B-500bとさほど変わらないだろうという想定で、同じ高さの記録面が並んでいるものと解釈した。

どちらにしても、2つずつ同じ高さの記録面があることは変わらない。組の中にきっかり同じ高さの面があること自体は、他のHDDを見ても珍しくはない。

4.3. 5400.5-320の場合


5400.5-320の2台はHD Tune Proで全体を見たときの形がよく似ているので、重ねてみると以下のようになる。
Momentus 5400.5-320: HD Tune Pro (Seq. Read, 320GB, 64KB, Full) compiled

これを見ると、
  • いずれもゾーンの変わり目がはっきり出ている。ゾーン数は16ということが分かるので、番号を振ってみた(0から始まるのはHGSTのSpecificationに倣ったもの)。
  • 高さの違いはあれ、形状はほとんど同じなので、5400.5-320aと320bの間でゾーンごとの容量は同じであることが分かる。
ゾーンの違いがはっきり出るのは、各ゾーン内の速度(平均)が一定であることを意味する。これから、ゾーンを構成する記録面にずれがない=各記録面のゾーンが一斉に変わっていることが予想できる。

まず5400.5-320aについて、Iometerでゾーン0(先頭)とゾーン1(39GB付近)を見たのが以下。
Momentus 5400.5-320 a: Iometer (Seq. Read, 64KB)Momentus 5400.5-320 a: Iometer (Seq. Read, 64KB)

ゾーン0の波形はHD Tune Proの結果と大体一致する。ゾーン1の方はかなり形が変わっているが、明らかに過大な値を出している面がある。この後のゾーンも過大な値が出るので、あまり信用できない。

ゾーン0からゾーン1への変わり目は、全体のグラフにも出ているように27GB付近にあった。5K500.Bと同じように各記録面にA、B、C、Dと付けてみたのが以下。
Momentus 5400.5-320 a: Iometer (Seq. Read, 64KB)

全ての面が一斉に高さを変えているのが分かる。A面は少し上がり、C面とD面は下がっている。B面が飛び出しているが、これは過大な値に見える。

Iometerがあてにならないので、DiskSpeed32で大まかな形だけでも追ってみる。一挙、全16ゾーン。バラツキがあるので、2回の計測結果を重ねた。
Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32Momentus 5400.5-320 a: DiskSpeed32

上下の動きは激しいが、値自体はIometerよりそれらしい。かなり乱れがあるものの、ゾーンが変わっても波形の基本的な形は変わってないらしい(段々小さくなっていくが)ことが分かる。

この結果から以下のように考えてよさそうである。
  • 全ての記録面が一斉にゾーンを変えていく。つまり、同じゾーンなら記録面ごとの容量は同じ。
  • ゾーンが変わるときに速度が下がる割合もほぼ同じ。つまり、記録面の間の線記録密度の高低関係はゾーンが変わっても固定されている。
5400.5-320bについても同じ計測をしたが、同じ傾向だったので省略。

4.4. MK3263GSXの場合


HD Tune Proで全体を見ると、非常に安定してゾーンが下がっていくことが分かる。ゾーン数は36ある。
MK3263GSX: HD Tune Pro (Seq. Read, 320GB, 64KB, Full)

とりあえずIometerでゾーン0(先頭)、ゾーン1(18GB付近)、ゾーン2(30GB付近)を見ると、以下のようになる。
MK3263GSX: Iometer (Seq. Read, 64KB)MK3263GSX: Iometer (Seq. Read, 64KB)MK3263GSX: Iometer (Seq. Read, 64KB)

ゾーン0はHD Tune Proの結果とほぼ同じ。ゾーン1、ゾーン2は同じ波形で全体的に下がっているのが分かる。

一気に飛んでゾーン10、ゾーン20、ゾーン30を見ると以下のようになる。

同じ形を保ったまま小さくなっていくのが分かる。ゾーン30まで来ると記録面間の高低差がなくなってくる。

ゾーンの変わり目はどうかというと、ゾーン0からゾーン1への境界(12GB付近)は以下のようなもの。5K500.Bと同じように各記録面にA、B、Cと付けてみた。
MK3263GSX: Iometer (Seq. Read, 64KB)

全ての記録面が一斉に下がっているのが分かる。なお、単純な繰り返しか、折り返しなのか判断できる材料がないので、A面とC面は入れ替わっているかもしれないが、どちらでも違いはない。

全体のグラフから予想できるように、各記録面間の差、ゾーン間の差が少なく、全体的に波乱のない安定した構成になっていることが分かる。

DiskSpeed32の結果も同じ傾向で、波形が鈍っているだけなので省略。

4.5. WD2500BEVSの場合


まずIometerは速度が常に144MB/s程度になり(X61sのSATAのインターフェイスのほぼ上限)、明らかに過大なので使えない。

とりあえずDiskSpeed32の結果から先頭、50GB、100GB、150GB、200GBの位置を見ると、以下のようになる。バラツキがあるので2回の結果を重ねた。
WD2500BEVS: DiskSpeed32WD2500BEVS: DiskSpeed32WD2500BEVS: DiskSpeed32WD2500BEVS: DiskSpeed32WD2500BEVS: DiskSpeed32

形の特徴が捉えにくいが、HD Tune Proで見た先頭1GBの波形に似てなくもない。

4.6. 中間まとめ


以上をまとめると、
  • 問題の波形はHDDの先頭以外にも続いていることが確認できた。

  • 5K500.Bでは各記録面のゾーンがバラバラに入れ替わっていくこと、5400.5とMK3263GSXでは全ての記録面のゾーンが一斉に変わっていくことが分かった。
次に応用について。