Hatena::ブログ(Diary)

Lansenの現実逃避日記 このページをアンテナに追加 RSSフィード

2011-05-06

[]Marvell/AMDドライバにおけるTrimの効果を検証 23:09 Marvell/AMDドライバにおけるTrimの効果を検証を含むブックマーク Marvell/AMDドライバにおけるTrimの効果を検証のブックマークコメント

震災新生活World of Tanks(参考)にと、いろいろ時間を取られているうちに5月になってしまいました。というわけで、久方ぶりに更新してみます。

以前の記事において、MarvellのSATA3チップ(88SE9123/88SE9128)のドライバや、AMDチップセットのAHCIドライバではTrimが送信されないと書きましたが、前者はバージョン1.0.0.1051、後者はバージョン1.2.1.275においてTrimに対応したとのことです(参考:Be Hardwareの記事)。というわけで、今回の記事では、それぞれのドライバにおけるTrimの効果を簡単に計測してみました。

テスト方法とP55チップセットによるリファレンス計測

テストは基本的にHD Tune ProWriteテストの結果を見るというお手軽なものです。実行方法は以下の通りです。

  1. HDDEraseでSSDにSecureEraseを実行
  2. HD Tune ProWrite Testを実行(1回目, 最高パフォーマンス)
  3. Iometerを用い、ディスク全域に4KBのランダムライトを30分実行
  4. HD Tune ProWrite Testを実行(2回目, パフォーマンス劣化状態)
  5. ディスク全域にクイックフォーマットドライブを作成し、すぐに消去
  6. HD Tune ProWrite Testを実行(3回目, 全域Trim実行後)

使用したSSDはSolidataのK5-64(Barefootコントローラ,SLC,64GB)です。Barefootコントローラは全域に対するTrimで容易に最高パフォーマンスに近い状態まで性能が回復するので、このようなテストには適しています。

HD TuneのWrite Testは、Partial Test(Most Accurate), Test Size 128KBの設定で実行しました。Full Testだとシーケンシャルライトになってしまうので、飛び飛びのアクセスパターンになるPartial Testにしてみました。テストサイズは適当です。

リファレンスとして、P55チップセットのSATA2ポートにおいてテストを実行してみました。使用したマザーボードはASRock P55 Deluxe, OSWindows 7 64bit (Professional Edition)です。ドライバIRSTのバージョン9.6.0.1014です*1

f:id:Lansen:20110506230254p:image

f:id:Lansen:20110506230253p:image

  • 3回目, 全域Trim実行後

f:id:Lansen:20110506230252p:image

以上のように、劣化した状態からほぼ完璧に性能が回復します。

Marvell 88SE9123

Marvell 88SE9123は、SATA3(6Gbps)に対応したコントローラチップで、一部のマザーボードのSATA3ポートや、PCI-Express接続のSATA3ポート増設カードなどに採用されています。このチップは、Trimに対応していないだけではなく、ICH10などのSATA2ポートよりパフォーマンスが劣ることがある(参考BenchmarkReviewsの記事)、ホットスワップに対応していないなど、いまいち感の漂う製品でした。しかし、Trimに対応したことで、目に見える欠点は一つ克服されたと言えそうです。

今回用いたハードウェアは、ASRock P55 Deluxeに付属していたSATA3カード(参考:AKIBA PC Online!の記事)です。 OSは上述のSATA2ポートテストと同じく、Windows 7 64bit (Professional Edition)です。ドライバのバージョンは1.2.0.1002で、Station-Driversからダウンロードしました。

f:id:Lansen:20110506230751p:image

f:id:Lansen:20110506230251p:image

f:id:Lansen:20110506230250p:image

  • 3回目, 全域Trim実行後

f:id:Lansen:20110506230249p:image

IntelのSATA2ポートよりピーク性能が下がっているのが気になるところですが、Trimはしっかり送信されているようで、ほぼ完璧に性能が回復しています。

AMD 790GX

AMDチップセットは、Intelに先駆けて880FX/880GXチップセットなどでSATA3に対応し、注目を集めていました。パフォーマンスは前述のMarvellのチップより高い傾向にあるようです(参考:PC Watchの記事)。

本当はSATA3のポートで試したいところでしたが、自宅には1世代前の790GXチップセット搭載のマザーしかなかったので、それを用いました。

使用したマザーボードは、BIOSTARのTA790GX XEで、OSWindows Server 2008 R2です。使用したドライバのバージョンは1.2.1282です。ドライバ公式ページからダウンロードできるもの(AHCI for Windows 7)です。なお、HD Tuneのライセンスは1つしか持っていないので、こちらのPCでは体験版を用いました。

f:id:Lansen:20110506230750p:image

f:id:Lansen:20110506230328p:image

f:id:Lansen:20110506230327p:image

  • 3回目, 全域Trim実行後

f:id:Lansen:20110506230326p:image

なぜかこれまでの2つに比べてTrim送信後の回復が完璧ではありませんが、Trimが有効であることは間違いなさそうです。

結論

いずれのチップセットでも、Trimが効果を発揮しているのが確認できました。最新のドライバさえインストールすれば、安心してSSDを使うことができそうです。

それぞれのチップセットの性能差は若干気になるところです。いずれ検証してみたいと思います。

おことわり

東日本大震災による関東地方の電力需給逼迫のため、SSD耐久テストは自粛中です。ご了承ください。

*1:最新版じゃなかったことにさっき気がつきました…

エクスエクス 2011/05/18 10:51 はじめまして。
自分のPCはAtom330/ION、つまりNVIDIAのチップセットなのですがIntelのX-25Mの160GB(G2)をパーティションを区切って使っています。
で、パーティションを区切っているからか?チップセットがインテルじゃないからか?は分かりませんがデフラグ・プリフェッチなどすべて有効になってました。(手動で無効にしました)
もちろんインテルツールボックスも使えませんがTrimは有効になっているようで1年半使っていますが性能劣化は起きておりません。

SSDは未だ謎が多いですね…

LansenLansen 2011/05/20 00:45 はじめまして。
あら、デフラグも無効になりませんでしたか…
デフラグ無効は成功している例がほとんどのようですが、何か条件があるのかもしれませんね。
Intel Toolboxが使えない、というのはソフトが起動しないということでしょうか?それともIntel SSD Optimizerなどが走らないということでしょうか?
TrimはWindows 7標準のAHCIドライバなら問題ないようですので、Intel SSD Optimizerを別途実施する必要はおそらく無いと思いますが、なんか気になりますね。

jungjung 2011/07/17 02:53 こんばんは。
SSDの情報探し回ってここにたどり着きました。

ちょっと気になる記事があったのでご紹介します。
http://www.itmedia.co.jp/enterprise/articles/1107/16/news001.html
価格や容量云々はおいとくとして、デフラグ必要って明言してるのが気になります。
何の根拠も示さないでそんなこと言われましてもねぇ

yamarahyamarah 2011/07/17 12:19 この記事、ひどいですよね。
あまりにひどいので、編集部にメールしましたよ。

LansenLansen 2011/07/18 00:51 SSDはコントローラによって特性がかなり異なるので、十把一絡げに必要だとか不要だとか言い切ってしまうのは若干抵抗がありますね。
HDDの時ほどの頻度でデフラグする必要がないのは間違いないと思いますが…

yamarahyamarah 2011/07/18 17:50 >HDDの時ほどの頻度でデフラグする必要がないのは間違いないと思いますが…
SSDをATAコマンドではデフラグ出来ないと認識しているのですが。
もちろん、SSDコントローラ固有のコマンドを使えば、その限りでは無いでしょうけど。
ATAコマンドで出来ることは、XPで空きセクタにTrimをするぐらいかな。
でも、これもデフラグではない。

LansenLansen 2011/07/18 23:11 あ、すいません。デフラグというのは論理アドレスレベルでのデフラグのことです。
物理アドレスレベルのデフラグ(ガベージコレクションって呼ぶことの方が多い?)はコントローラ依存ですから、何がどうなっているかは神のみぞ知るってところですね。
論理アドレスレベルのデフラグをすればガベージコレクションも容易になりますし、ランダムライトの発生も抑えられるので、論理アドレスレベルのデフラグが無意味ってことは無いはずです。しかし、それが実使用上どのぐらいの効果があるのかは議論の余地があると思います。

yamarahyamarah 2011/07/19 21:37 >論理アドレスレベルのデフラグが無意味ってことは無いはずです
えっ? そんなはずは・・・と思って、いろいろググってたら、このブログに戻ってきました(笑)

http://d.hatena.ne.jp/Lansen/20090211/

理屈ではありえないと思っていたのですが、実際にやってみると、効果があるのですね。

言葉遊びのようですが、これは、
「空き領域が連続したことで、シーケンシャルライト性能が上がった」
のではなく、
「空き領域が連続していた場合に良い結果が出るような、シーケンシャルライトテストをした」
って事では無いでしょうか。
CrystalDiskMarkのアルゴリズムはわからないのですが、シーケンシャルテストは1MBの連続アクセスのようです。
http://crystalmark.info/software/CrystalDiskMark/manual-ja/Faq.html
この1MBって、論理セクタ空間で連続していることは保障しているんでしょうか。
また、同じ1つの1MBのファイルを読み書きするのか、次々と別の1MBのファイルに移るのか。この辺りがわからないと、これ以上の考察は難しいかな・・・

いずれにせよ、JMコントローラのころはいざ知らず、Trimに対応しているようなコントローラなら、効果が無いような気がします。

suomisuomi 2012/01/21 00:10 今晩は。

SSDの速度低下を改善するのに、ゼロフィルではダメでワンフィルを使う、という話題があったと思いますが、どのあたりだったでしょうか。

LansenLansen 2012/01/21 17:01 うーん、0Fillではダメって話はちょっと記憶にないですね…
IntelのSSDはシーケンシャルライトを行うと性能が回復します。
0Fillで速度回復するのは、書き込む内容が0なのが効いているわけではなく、シーケンシャルライトが行われたということが重要なんですね。
なので、書き込む内容は0でも1でもランダムでも大丈夫だと思います。
なお、IntelのSSDは、現在ではTrimやSSD ToolBoxによって速度回復するので、0Fillで回復というのは既に過去の手法になっています。

suomisuomi 2012/01/23 23:49 ども。いやー、どこかにあったと思うのですが。(^_^;) FF FILLで速度回復させる実験。

>>0Fillで回復というのは既に過去の手法になっています。

それはそうですが。こういう事を試行する、という苦しさが最先端を走っている人にはわからない。プチフリ(ストール)が頻繁に起こってどうしようもなくなった、PhotoFast 1.8インチ日立型 SSDを救済する話なんです。

結局なんきょく、HDDErase.exeを使ったSecure Eraseには失敗。wipe-outを使って、ワンフィルを行いました。実感としてほぼ回復しようです。

SSDでSecure Eraseを試す【追記あり】
http://fooen79.blog10.fc2.com/blog-entry-14.html

ハードディスク消去ツール「wipe-out」
http://www.wheel.gr.jp/~dai/software/wipe-out/

ThinkPad X40で1.8インチ日立型SSDに苦労する、というのは極端ですが。数年前のトランセンドの類のJ-Micron IDE SSDで苦労している人はたくさんいると思います。

LansenLansen 2012/01/26 00:54 あ、すいません。1.8インチですか…
選択肢が少ないと困りますよね。
最近だとMach Extremeの製品しか見かけないような気がします。
JMicronコントローラはHDDEraseには対応してないはずです。
空き領域のデフラグは効果あるはずなので、MyDefragかDefragglerを試してみるといいかもです。

KakakkunKakakkun 2012/06/02 12:50 どうやら変な?ところに書き込んでしまったようですいません。
JMF612はもう旧世代になったようですが、JSMonitorリリース後のコントローラ
という意味です。

LansenLansen 2012/06/06 23:59 すいません、最近完全にサボっていてソフトもBlogも全然更新していません…
大部分のSSDはCrystalDiskInfoが対応していますので、そちらをご使用ください。

2011-03-07

[](5) 平均書き換え回数5000回到達 02:36 (5) 平均書き換え回数5000回到達を含むブックマーク (5) 平均書き換え回数5000回到達のブックマークコメント

D論炎上しすぎワロエナイ、という状況だったため長らく更新をサボっていましたが、耐久テスト継続して実行していました。ようやく色々と終わったので、更新を再開したいと思います。晴れて来年度からは学生身分を脱却できそうです。

現在のテストの状態ですが、Onyx(Intel製NAND),UltraDrive GX2(東芝製NAND)の両方とも、平均書き換え回数が寿命の目安と言われる5000回に到達し、データ保持エラーの影響を調べるための2度目の放置実験を行っているところです。テストの内容については、前々回の記事を参照してください。

Onyxの方は、なかなかお目にかかれないCrystalDiskInfoの"異常"状態に到達しました。UltraDrive GX2の方は、寿命の上限が10,000回に設定されているため、まだ正常の状態です。

f:id:Lansen:20110308023912p:image

さて、寿命の目安とされる書き換え回数には到達したものの、未だにOnyxの後天的な不良ブロックは0、Ultradrive GX2でもProgram Failure Blockが1個(テスト初期に発生)のみであり、すぐさまSSDが壊れそうな雰囲気は感じられません。

RBERの面からも、やはりすぐに壊れそうな雰囲気はありません。

以下に、前回同様のRBERのグラフを示します。縦軸がRBER(logスケール),横軸がAverage Erase Countです。赤はOCZ Onyxの全データにおけるRBER、緑はOnyxの最後の一周のRBER(一周=LBAの先頭から最後まで読み書きを行うことと定義)、青はSuperTalent UltraDrive GX2の全データにおけるRBER,ピンクはUltradrive GX2の最後の一周のRBERです。"+○○hours"と表記されている矢印は、最後に書き込みを行ってからの経過時間を示しています。

f:id:Lansen:20110308023913p:image

JEDECの基準では、SSDの生涯を通したUBERが10E-15を下回ることが要求されています。8bitのECCを用いる場合、UBERが10E-15となるRBERの閾値は約5.61E-5, 12bitのECCを用いる場合のRBERの閾値は1.94E-4となります。

テストにおいては、RBERは順調に増加してはいるものの、全データのRBER(赤、青)はおろか、最後の一周のRBER(緑、ピンク)ですらそれらの閾値を大幅に下回っています。やはり、目安とされる書き換え回数の上限に到達しても、即座にSSDが機能を失う、多くのデータが破損するといった現象が発生することは考えにくい状況です。

あとは長時間の放置によるデータ保持エラーがどのくらい発生するか、ということがポイントになりそうです。興味深いことに、東芝のNANDは、平均書き換え回数5,000回到達後のデータ保持エラーの影響が小さいようで、RBERはほとんど増えていません。一方、IntelのNANDは盛大にRBERが上昇中です。

以前紹介したJEDECの基準には、長期にわたるデータ保持エラーの影響を推定する手法が記載されています。次回は、2回の放置実験それぞれについて、その手法を試してみたいと思います。

cuttingedgecuttingedge 2011/03/08 05:50 D論、お疲れさまです。(自分の場合、要求される筆頭著者2報目のaccept letterがなかなか来ず、結構あせりました。コラボしていた海外の研究者とのFaxのやり取りで、朝になると受信した感熱Fax用紙がとぐろを巻いているのを目にしてゾッとする日々でした。20年近く前の懐かしい話ですw)

さてもうすぐリリースされそうなOCZ Vertex 3シリーズですが、各サイトでレビューされている評価版のNANDをみると、Vertex 3ではIMFT 25nm NANDが、Vertex 3 Proは東芝の32nm NANDが使用されているようです。価格や書き換え寿命もさることながら、上の結果をみると、要求水準は低いとしてもデータ保持エラーを考慮してそういう選択なのかも知れないですね。ただ、Vertex 3 Proがエンタープライズ用途で実際にどの程度アピールするかは微妙な感じはしますが・・・

LansenLansen 2011/03/09 02:57 どうもです。僕の場合は1章で「〜を実現した。」と書いてあることが年が明けてもまだ実現できてないというしょーもない状況でした…

そういえば前作のSF-1500搭載SSDってエンタープライズ用途でどのくらい使われてるんでしょう?
Fusion-ioの導入事例は見かけますが、Sandforceの話はあまり聞かないような??

cuttingedgecuttingedge 2011/03/09 05:54 SMART Modular TechnologyのトップモデルXceedIOPSがSF1500系のようですが、実際の導入事例はどうでしょう...
http://www.tweaktown.com/articles/3721/smart_modular_xceediops_sf_1500_powered_sas_ssd_preview/index3.html

LansenLansen 2011/03/11 02:51 なるほどこんなのがあるんですね。
ソリューションとして組みこまれないと普及は難しいかもしれませんが…

TDTD 2011/03/21 07:09 検証お疲れ様です。
Intel 510とMicron C400がややインパクトに欠けるので
SF-2000系統とIntel 320に何とかしてもらわないと。

個人的にはSF-2000系統を購入しようかと考えてますが
OCZはファームウェア(の扱い)がいまいち信用できず
代わりにどこのを買おうか悩ましいところです。

そういえば東芝、何してるんでしょうかね。

LansenLansen 2011/03/22 00:20 今は新製品ラッシュですね。東芝さんも負けずについて行ってほしいところです。
さすがに今回はいずれも性能面では問題なさそうです。
逆にどれがいいのか見極めるのはちょっと大変そうですね…
Sandforce搭載製品はどの会社でもそんなに変わらないような?OCZはむしろファームウェアアップデートが早くて頻繁なのでまだマシかもって気もします。

yamarahyamarah 2011/04/01 22:49 こんにちわ。

私のFTM28GX25H(ブートデバイス)が使用中にロストする(Windowsから見えなくなる)ようになり、
発生周期が加速度的に短くなってきて、焦ってHDDにシステムコピーしました。
HDDにTrueImageでコピーしたシステムは全く落ちないので、SSDのハードトラブルっぽいです。

そこで、落ち着いたところでSMART情報を調べていて、こちらにたどり着きました。
エラーの出た個体は、最大消去回数に変な偏りがあります。
主だったSMART値を挙げると、
09 使用時間 C00
CD 規定最大書き換え回数 1388
CE 最小消去回数 2
CF 最大消去回数 105CE
DO 平均消去回数 52E
D1 残り寿命 4A

ほぼ同じ構成のマシンがもう1台あるのですが、それは
09 使用時間 347
CD 規定最大書き換え回数 2710
CE 最小消去回数 C7
CF 最大消去回数 58F
DO 平均消去回数 34D
D1 残り寿命 3F

1つ目のSSDは、本当にウェアレベリングが行われているのか怪しい値ですよね。

LansenLansen 2011/04/02 16:46 105CEってことは67022回消去済みってことですね…
それは不具合が出てもおかしくありません。
ちなみに、ファームウェアのバージョンはいくつになっていますか?
1571以前のファームウェアはバグの影響で最大消去回数が異常に大きくなってしまうので、アップデートをおすすめします。
なお、ファームウェアアップデータは以下のアドレスからダウンロードできます。
http://www.supertalent.com/support/driver_download.php

2010-12-19

[](4) 平均書き換え回数2500回到達 23:38 (4) 平均書き換え回数2500回到達を含むブックマーク (4) 平均書き換え回数2500回到達のブックマークコメント

現状報告

両者のAverage Erase Countが2500回に到達し、現在はデータ保持エラーテスト中です。これまでのテストでは書き込みエラーを調べるために書き込みと読み込みを交互に行っていました。これからしばらくはドライブへの書き込みを行わず、時々リードオンリーのテストを行ってRBERの推移を計測します。結果の生データは前回と同様に以下のリンクからダウンロードすることができます。

OCZ OCZSSD2-1ONYX32Gのログ

Super Talent STT_FTM64G225Hのログ

現在のRaw Bit Error Rate(RBER)の状況をグラフにすると、以下のようになります。

f:id:Lansen:20101219223358p:image

縦軸がRBER(logスケール),横軸がAverage Erase Countです。

赤はOCZ Onyx(Intel,34nm)の全データにおけるRBERを、緑はOnyxの最後の一周のRBER(一周=LBAの先頭から最後まで読み書きを行うことと定義)を示します。同様に、青はSuperTalent UltraDrive GX2(東芝,43nm)の全データにおけるRBERを,ピンクはUltradrive GX2の最後の一周のRBERを示します。

また、最後の方に"+142hours", "+275hours"とある矢印の先が、データ保持エラーを調べるためのリードオンリーテストの現状の結果です。それぞれの値は最後にデータを書き込んでからの時間を示します。

概ねAverage Erase Countに従ってRBERも上昇していますが、Onyxの300回ぐらいのところとUltraDrive GX2の400回ぐらいのところにRBERが急上昇しているところがあります。この間にテストのためのPCを変更したのですが、プログラムは同じものを使っているので、この現象の原因はよく分かりません。考えられることとしては、アイドル中にスタティックウェアレベリングが行われてたまたまエラーの多いブロックが使われるようになったためか、あるいは温度要件が変化したため、と言ったところでしょうか。この点に関しては、Indilinx Smart Viewerの結果なども調査して原因を調べてみます。

温度要件と放置実験の要領

NANDフラッシュエラーレートは温度にかなり強い影響を受けるので、厳密な試験を行うためには恒温槽などを使うのが望ましいようです。当然そんなものは自宅にはないのですが、せめてSSDの雰囲気温度ぐらい計測しておこうと思い、プローブ付きで最低・最高温度を計測可能な温度計を買ってみました。一週間ぐらいケース内のSSD周辺の温度を測ってみたところ、最低温度21.3度、最高温度27.6度でした。この温度計には平均温度を測る機能は付いていませんが、ふと見ると23〜24度台になっていることが多かったように思います。

というわけで、外に出しておくよりは温度が安定していそうなので、放置実験はケース内にSSDを入れっぱなしにします(PCサーバ用なので24時間稼働)。ただし、Indilinxアイドル中にスタティックウェアレベリングガベージコレクションをしているらしく、OSから何もしていなくてもErase Countが増加してしまいます*1。そのため、普段はSSDには電源を入れず、テストを行うときだけケーブルを接続することにしました。

プログラム公開

ソースは汚いままなのですが、放っておいても一生きれいにならない予感がするのでもうこのまま公開します。コンパイルにはBoost 1.44とVisual C++ 2010が必要です(Express Editionでも大丈夫なはず)。

IDXEnduranceTester

起動後にドライブ選択->リードオンリーテストリードライトテストかを選択->リードライトの場合目標Average Erase Countを設定->テスト開始となります。なお、テスト中にIndilinx SMART Viewerを呼び出すようになっているので、IDXEnduranceTester.exeと同じフォルダにSmartViewer_2_21.exeを置く必要があります。

*1:SuperTalentの読み書きのテスト終了時にはAverage Erase Countが2500、Maximum Erase Countが2712だったのですが、気がついたらそれぞれ2501,2756に増えていました。

dejavudejavu 2010/12/20 11:43 Onyxの300回ぐらいのところとUltraDrive GX2の400回ぐらいのところにRBERが急上昇というのが気になりますね。
しかも、Onyxに関しては、その後RBERの数が減っていっています。

可能性としてはData Retentionですかね。
PCを変更するのにどのくらいの時間がかかったのでしょうか?

Data Retentionだと、一度書き換えてしまえばリセットされるのでRBERが減少していくのも辻褄が合いそうです。

ひよひよひよひよ 2010/12/21 23:59 こうやって実験して定量的に評価するのはやっぱりいいですね。
綺麗な右肩上がりで使えば使うほど劣化する様がよくわかります。

ところで、Uncorrectable Bit Error Rate(12bitECC) だと 1E-50 以下と普通に頑張ってもエラー発生を拝むのは難しい感じですね。今どきの ECC はこんなにも強力なのか・・・ちょっと驚きました。

さすがに実行ファイルがついていないとハードル高いかも。
私も Boost をインストールしてまで試そうとは・・・。

LansenLansen 2010/12/22 03:20 >dejavuさん
放置時間は約半日ぐらいでした。
緑色のデータは書き込み・読み込みを交互に行ったテストの最後の一周のみのRBERのデータなので、書き込みを行った直後に読み込みを行っています。
なので、データリテンションの影響は受けないはずなんですが、かといってこの現象をうまく説明できる他の説明があるわけではないんですよね…
ちなみに、書き換え回数が増えたのにRBERが下がるという現象自体は無いわけではないようです。
http://pc.watch.impress.co.jp/docs/2008/0507/irps_2.jpg
↑のデータでは、○と□のNANDでそういう現象が起きてますね。

>ひよひよさん
Intelはちょっと怪しいですが、東芝の方は予想よりかなりきれいなデータになりました。
現状では、理論的にはデータ化けは起きそうにないですね。
全体のRBERが10E-6を切ったあたりからが本番でしょうか。

すいません。後でバイナリも入れておきます。まあプログラムはIndilinxコントローラ搭載SSDじゃないと走らないんですが…
ちなみに、Boostは一回使うと手放せなくなりますので、この機会にぜひ試してみてください(笑

dejavudejavu 2010/12/24 22:21 >Lansenさん
半日だけの放置なら、高温にして放置しない限り、Data Retentionじゃないですね。

キャッシュメモリがPC交換のために電源オフされることによってクリアされたと思います。このことは影響ありそうですか?
(キャッシュレスのSSDでしたっけ??)

LansenLansen 2010/12/26 23:55 これらのSSDは両方とも64MBのDRAMを搭載しています。
なので、電源のオンオフが何かのトリガになってる可能性はありますね。
具体的に何が起こるはずだ、というのは断定できないのですが…

2010-11-19

[](3)耐久テスト開始 02:44 (3)耐久テスト開始を含むブックマーク (3)耐久テスト開始のブックマークコメント

大変遅くなってしまいましたが、ようやく耐久テストを開始できたので、テストのセットアップについて紹介します。

何度も書いていることですが、僕はSSDについてもNANDについても専門家ではありません。従って、間違った理解や不適切なテストを行っている可能性もあります。ご意見・ご助言等は常に募集中です。よろしくお願いします。

テストの目的

  1. SSDに連続して読み書きを行い、その耐久性について調べる
  2. SMARTを通して豊富情報を取得できるIndilinxコントローラ搭載のSSDを用いることにより、書き込み量に対するNANDの状態変化について調べる
  3. Intel製NANDを搭載するOCZ OCZSSD2-1ONYX32Gと、東芝製NANDを搭載するSuperTalent FTM64G225Hの2種類のSSDに対してテストを行い、それらのNANDの間の差を調べる

IndilinxコントローラSMARTについては以前の記事に詳しく記しています。

テスト全体の流れ

現在の予定としては、以下のようにテストを行うことを考えています。

  1. Average Erase Countが2500になるまで読み書きを実行
  2. 30日程度電源を入れずに放置、ときどき読み込みのみのテストを行う
  3. Average Erase Countが5000になるまで読み書きを実行
  4. 30日程度電源を入れずに放置、ときどき読み込みのみのテストを行う
  5. 状況を見てそれ以降のテストを追加

一応の目安と言われている5000回の書き換えが発生するまでテストを行う予定です。電源を入れずに放置するのは、データ保持エラーの大きさについて調べるためです。現実的な時間として30日程度の放置期間としますが、この長さはまあ適当です。状況に応じて延長・短縮するかもしれません。

テスト方法

テストは以下の手順で行います。

  1. 1MiB単位で1GiBのシーケンシャルライトを行う
  2. 同じ領域にシーケンシャルリードを行い、データをVerifyする。もしデータが破損していた(書き込みデータと異なっていた)場合、破損が発生したセクタ数及びビット数を記録する
  3. SMART情報を取得し、重要な値が変化していた場合ログに保存する
  4. LBAの末尾に到達するまで1-3を繰り返す
  5. SMART情報を取得してログに書き込み、さらにBarefoot/Amigos SMART Viewer v2.21(不定記[exa5]さんによる解説)を実行して結果を保存する
  6. Average Erase Countが規定値(2500または5000)に到達していればテスト終了、そうでなければ書き込みアドレスを先頭に戻してテストを再開

書き込みと読み込みを相互に行わずに1GiB単位で読み書きを行うのは、書き込みキャッシュによる影響を避けるためです。最初は書き込みを1MiB行った直後に同じところを読み込むようにプログラムを組んだのですが、その仕様だと読み込みもキャッシュから行われてしまうようで、全くSMARTのBit Errorが変化しませんでした。

また、Barefoot/Amigos SMART Viewerを用いると通常のSMARTよりもさらに詳細な情報を取得できるのですが、自作のプログラムからそれらの情報を取得する方法は分かりません。そこで、SmartViewer2_21.exeを起動し、無理矢理キーストロークを送信してデータを取得するようにプログラムを作成しました。

ログの内容

プログラムJSMonitorソースを流用して作成しており、JSMonitor同様にSMARTの値のログをcsv形式(カンマ区切りのデータ)で保存します。また、SMARTの値に加え、下記の値を計算して保存しています。

カラム項目名解説
XRaw Bit Error Rate(Calculated)ECC使用前のビットエラーの頻度(参照、全データを使用)
YUncorrectable Bit Error Rate(8bitECC)8bit ECC使用後のビットエラーの頻度の推定値(全データ)
ZUncorrectable Bit Error Rate(12bitECC)12bit ECC使用後のビットエラーの頻度の推定値(全データ)
AARaw Bit Error Rate(Last Round)ECC使用前のビットエラーの頻度(最後の一周のみ)
ABUncorrectable Bit Error Rate(8bitECC Last Round)8bit ECC使用後のビットエラーの頻度の推定値(最後の一周のみ)
ACUncorrectable Bit Error Rate(12bitECC Last Round)12bit ECC使用後のビットエラーの頻度の推定値(最後の一周のみ)
ADUncorrectable Bit Error Count破損したビットの総数
AESector Fail Count破損したセクタの総数
AFRead Speed(MB/s)シーケンシャルリードの速度
AGWrite 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なのでExcelOpenOffice.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になりましたが、ビットエラーなどの異常は特に発生しませんでした。

そのほか

いずれプログラムも公開する予定ですが、現時点ではあまりにソースが汚いので、少し整理した後に公開します。また、テストについてさらに詳細な情報についても追って掲載します。

cuttingedgecuttingedge 2010/12/08 00:06 おおっ、スパタレはもう少しで2500ですね。

LansenLansen 2010/12/08 02:17 一時間ほど前に2500に到達していました。
当然と言えば当然ですが、まだエラーレートは問題にならないほど低いですね。

KakakkunKakakkun 2012/06/02 12:43 どうも初めまして。

最近JSMonitorの更新がありませんが、JMF612など新型への対応はありませんか?

2010-10-24

[]SuperTalent FTM64G225H (UltraDrive GX2シリーズ)のベンチマーク 21:59 SuperTalent FTM64G225H (UltraDrive GX2シリーズ)のベンチマークを含むブックマーク SuperTalent FTM64G225H (UltraDrive GX2シリーズ)のベンチマークのブックマークコメント

ついつい買ってしまいました。本当は32GB版を買おうかと思っていたのですがどこも品切れなので、64GB版にしました。

UltraDrive GX2シリーズはIndilinxコントローラ東芝のNANDを搭載しているので、Onyxと同時にテストすれば東芝IntelのNANDのRBERを比較することができます。なお、FTM64G225Hの容量はOnyxの倍の64GBですが、シーケンシャル性能もOnyxの倍ぐらいはあるので、時間あたりのAverage Erase Countの増加量は同じ程度になるはずです。

殻割り

f:id:Lansen:20101023142255j:image

…をしようと思ったのですが、困ったことにトルクスレンチなので開けられません。うーんどうしよう。そのうちどっかからレンチを借りてきます。

更新 2010/12/19

先端を交換できるドライバセットを買って開けてみました。

f:id:Lansen:20101121145906j:image

搭載NANDはTH58NVG5D2ETA20です。一つ勘違いしていたのですが、このシリーズは32nmではなく43nmのNAND搭載製品でした。

ちなみに、東芝のNANDは型番が**********ET***となっているものが43nm, **********FT***となってるものが32nmの製品のようです。同様にDTが56nm, CTが70nmと遡っていきます。

ベンチマーク結果

f:id:Lansen:20101024215546p:image

f:id:Lansen:20101024215545p:image

f:id:Lansen:20101024215544p:image

f:id:Lansen:20101024215543p:image

f:id:Lansen:20101024215542p:image

f:id:Lansen:20101024215541p:image

Onyxに比べるとシーケンシャルは圧倒的な性能ですが、ランダムリード性能はIndilinx系ではかなり低い部類です。自宅の環境がなんか変なのかと思ったのですが、AS SSD Benchmarkでの比較でも同様の結果となっているので、これはこういうもののようです。

JSMonitor

f:id:Lansen:20101024215540p:image

SSD耐久テスト Indilinx篇 序章(1)に記したのと同じ方法でRBERを計算すると、185,093/(228,876,619*4096)=1.97E-7となります。まだまだこの程度では問題にはなりませんが、Intelに比べると4倍近くRBERが多いようです。なお、SMARTのRead Error Rateは6と表示されています。ということは、この項目はRBERを四捨五入ではなく切り上げして乗数を表示しているっぽいですね。

あと何故かMaximum PE Count Specificationが10,000になってます。ファームウェア2030(OCZでは1.6)では、5xnm世代のNAND搭載の製品でも軒並み5,000まで下げられているのに、このNANDはなんで10,000のままなんでしょう?

ルミスルミス 2010/10/28 22:39 うちのADATAのS592のデータですと、RBERが1.28E-xあたりを超えると切り上げられるようでした。
S592ですとファームが古いので、一概に同じとは言えませんが

JJJJ 2010/11/07 10:17 トルクスのドライバー、ダイソーで売ってますよ。

LansenLansen 2010/11/09 23:37 長期間放置してしまってすみません…
>ルミスさん
手持ちの初代Vertex(30GB)の昔のJSMonitorのログからも計算してみたのですが、やはり切り上げになっていました。おそらく以前から同じ仕様だったのではないかと思います。

>JJさん
お、そんなマニアックなものまで100均で売ってるんですか…
専用ドライバを買ってしまうと邪魔になりそうなので、ビットを交換できるドライバセットを買ってこようかと思ってました。意外と安く売ってるみたいです(1000円以下)。
でも100円ならほぼ使い捨てでもいいかなあという気もしますね。