(3)耐久テスト開始
大変遅くなってしまいましたが、ようやく耐久テストを開始できたので、テストのセットアップについて紹介します。
何度も書いていることですが、僕はSSDについてもNANDについても専門家ではありません。従って、間違った理解や不適切なテストを行っている可能性もあります。ご意見・ご助言等は常に募集中です。よろしくお願いします。
テストの目的
- SSDに連続して読み書きを行い、その耐久性について調べる
- SMARTを通して豊富な情報を取得できるIndilinx製コントローラ搭載のSSDを用いることにより、書き込み量に対するNANDの状態変化について調べる
- Intel製NANDを搭載するOCZ OCZSSD2-1ONYX32Gと、東芝製NANDを搭載するSuperTalent FTM64G225Hの2種類のSSDに対してテストを行い、それらのNANDの間の差を調べる
Indilinx製コントローラのSMARTについては以前の記事に詳しく記しています。
テスト全体の流れ
現在の予定としては、以下のようにテストを行うことを考えています。
- Average Erase Countが2500になるまで読み書きを実行
- 30日程度電源を入れずに放置、ときどき読み込みのみのテストを行う
- Average Erase Countが5000になるまで読み書きを実行
- 30日程度電源を入れずに放置、ときどき読み込みのみのテストを行う
- 状況を見てそれ以降のテストを追加
一応の目安と言われている5000回の書き換えが発生するまでテストを行う予定です。電源を入れずに放置するのは、データ保持エラーの大きさについて調べるためです。現実的な時間として30日程度の放置期間としますが、この長さはまあ適当です。状況に応じて延長・短縮するかもしれません。
テスト方法
テストは以下の手順で行います。
- 1MiB単位で1GiBのシーケンシャルライトを行う
- 同じ領域にシーケンシャルリードを行い、データをVerifyする。もしデータが破損していた(書き込みデータと異なっていた)場合、破損が発生したセクタ数及びビット数を記録する
- SMARTの情報を取得し、重要な値が変化していた場合ログに保存する
- LBAの末尾に到達するまで1-3を繰り返す
- SMARTの情報を取得してログに書き込み、さらにBarefoot/Amigos SMART Viewer v2.21(不定記[exa5]さんによる解説)を実行して結果を保存する
- Average Erase Countが規定値(2500または5000)に到達していればテスト終了、そうでなければ書き込みアドレスを先頭に戻してテストを再開
書き込みと読み込みを相互に行わずに1GiB単位で読み書きを行うのは、書き込みキャッシュによる影響を避けるためです。最初は書き込みを1MiB行った直後に同じところを読み込むようにプログラムを組んだのですが、その仕様だと読み込みもキャッシュから行われてしまうようで、全くSMARTのBit Errorが変化しませんでした。
また、Barefoot/Amigos SMART Viewerを用いると通常のSMARTよりもさらに詳細な情報を取得できるのですが、自作のプログラムからそれらの情報を取得する方法は分かりません。そこで、SmartViewer2_21.exeを起動し、無理矢理キーストロークを送信してデータを取得するようにプログラムを作成しました。
ログの内容
プログラムはJSMonitorのソースを流用して作成しており、JSMonitor同様にSMARTの値のログをcsv形式(カンマ区切りのデータ)で保存します。また、SMARTの値に加え、下記の値を計算して保存しています。
カラム | 項目名 | 解説 | |||
X | Raw Bit Error Rate(Calculated) | ECC使用前のビットエラーの頻度(参照、全データを使用) | |||
Y | Uncorrectable Bit Error Rate(8bitECC) | 8bit ECC使用後のビットエラーの頻度の推定値(全データ) | |||
Z | Uncorrectable Bit Error Rate(12bitECC) | 12bit ECC使用後のビットエラーの頻度の推定値(全データ) | |||
AA | Raw Bit Error Rate(Last Round) | ECC使用前のビットエラーの頻度(最後の一周のみ) | |||
AB | Uncorrectable Bit Error Rate(8bitECC Last Round) | 8bit ECC使用後のビットエラーの頻度の推定値(最後の一周のみ) | |||
AC | Uncorrectable Bit Error Rate(12bitECC Last Round) | 12bit ECC使用後のビットエラーの頻度の推定値(最後の一周のみ) | |||
AD | Uncorrectable Bit Error Count | 破損したビットの総数 | |||
AE | Sector Fail Count | 破損したセクタの総数 | |||
AF | Read Speed(MB/s) | シーケンシャルリードの速度 | |||
AG | Write Speed(MB/s) | シーケンシャルライトの速度 |
"一周"というのは、書き込み・読み込みがLBAの先頭から末尾まで達したことを指します。AA-ACの値は、読み書きがLBAの末尾まで達した場合だけ計算されます。
UBERは、このクラスに一般的に求められる8bit ECCと、Barefootが搭載しているとされる12bit ECC(DailyTechの記事)のそれぞれを適用した場合を計算しています。なお、JEDECの耐久性基準では、全データのUBERが1.0E-15(Clientクラス)または1.0E-16(Enterpriseクラス)を越えないことが要求されています。
なお、Barefoot/Amigos SMART Viewerの結果は別途保存しています。per-CE Count Info,Bad Block Listはテキストファイルに保存し、Erase Count Listは別のcsvファイルに保存(正確にはSMART Viewerが作成するcsvファイルをリネーム)しています。
ログデータの公開
このまま順調にすすめば、Average Erase Countが2500に到達するのはSuperTalent(東芝NAND)が12月6日ごろ、OCZ(Intel NAND)が12月12日ごろになりそうです。それまで音信不通なのでは面白くないので、DropBoxのpublicフォルダの機能を利用してログファイルを公開することにしました。テストが一周終わる度にpublicフォルダにログをコピーしているので、十数分に一回程度は更新されています。
ダウンロードは以下のリンクから可能です。
OCZ OCZSSD2-1ONYX32Gのログ
Super Talent STT_FTM64G225Hのログ
前述の通り、ログ形式はcsvなのでExcelやOpenOffice.orgのCalcなどで参照することができます。Barefoot/Amigos SMART Viewerの結果は量が多いので今のところは公開していません。いずれ公開方法を考えたいと思います。
現時点の状況
購入直後のテストでは、OCZ(Intel NAND)よりSuperTalent(東芝NAND)の方がRBERが大きかったのですが、テストを進めるにつれSuperTalentのRBERは小さくなってきています。おそらく、最初にベンチマークテストを行った際に、SuperTalentはたまたまビットエラーが多い領域が頻繁に使われてしまったのでしょう。
現在では、OCZのRBERは約1.83E-07、SuperTalentのRBERは約1.81E-08となっており、OCZのRBERはSuperTalentに比べてちょうど10倍程度大きくなっています。
また、SuperTalentではProgram Failure Blockが1になりましたが、ビットエラーなどの異常は特に発生しませんでした。
そのほか
いずれプログラムも公開する予定ですが、現時点ではあまりにソースが汚いので、少し整理した後に公開します。また、テストについてさらに詳細な情報についても追って掲載します。