Hatena::ブログ(Diary)

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

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

トラックバック - http://d.hatena.ne.jp/Lansen/20110307/1299519412