Marvell/AMDドライバにおけるTrimの効果を検証

SSD

震災に新生活に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 ProのWriteテストの結果を見るというお手軽なものです。実行方法は以下の通りです。

  1. HDDEraseでSSDにSecureEraseを実行
  2. HD Tune ProのWrite Testを実行(1回目, 最高パフォーマンス)
  3. Iometerを用い、ディスク全域に4KBのランダムライトを30分実行
  4. HD Tune ProのWrite Testを実行(2回目, パフォーマンス劣化状態)
  5. ディスク全域にクイックフォーマットでドライブを作成し、すぐに消去
  6. HD Tune ProのWrite 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, OSはWindows 7 64bit (Professional Edition)です。ドライバはIRSTのバージョン9.6.0.1014です*1。

  • 1回目, 最高パフォーマンス

  • 2回目, パフォーマンス劣化状態

  • 3回目, 全域Trim実行後

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

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からダウンロードしました。

  • 1回目, 最高パフォーマンス

  • 2回目, パフォーマンス劣化状態

  • 3回目, 全域Trim実行後

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

AMD 790GX

AMDのチップセットは、Intelに先駆けて880FX/880GXチップセットなどでSATA3に対応し、注目を集めていました。パフォーマンスは前述のMarvellのチップより高い傾向にあるようです(参考:PC Watchの記事)。
本当はSATA3のポートで試したいところでしたが、自宅には1世代前の790GXチップセット搭載のマザーしかなかったので、それを用いました。

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

  • 1回目, 最高パフォーマンス

  • 2回目, パフォーマンス劣化状態

  • 3回目, 全域Trim実行後

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

結論

いずれのチップセットでも、Trimが効果を発揮しているのが確認できました。最新のドライバさえインストールすれば、安心してSSDを使うことができそうです。
それぞれのチップセットの性能差は若干気になるところです。いずれ検証してみたいと思います。

おことわり

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

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

(5) 平均書き換え回数5000回到達

SSD耐久テスト Indilinx篇

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

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

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

さて、寿命の目安とされる書き換え回数には到達したものの、未だに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"と表記されている矢印は、最後に書き込みを行ってからの経過時間を示しています。

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回の放置実験それぞれについて、その手法を試してみたいと思います。

(4) 平均書き換え回数2500回到達

SSD耐久テスト Indilinx篇

現状報告

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

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

縦軸が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に増えていました。

(3)耐久テスト開始

SSD耐久テスト Indilinx篇

大変遅くなってしまいましたが、ようやく耐久テストを開始できたので、テストのセットアップについて紹介します。
何度も書いていることですが、僕は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の値に加え、下記の値を計算して保存しています。

カラム 項目名 解説
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になりましたが、ビットエラーなどの異常は特に発生しませんでした。

そのほか

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

SuperTalent FTM64G225H (UltraDrive GX2シリーズ)のベンチマーク

SSD

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

殻割り


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

更新 2010/12/19

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

搭載NANDはTH58NVG5D2ETA20です。一つ勘違いしていたのですが、このシリーズは32nmではなく43nmのNAND搭載製品でした。
ちなみに、東芝のNANDは型番が**********ET***となっているものが43nm, **********FT***となってるものが32nmの製品のようです。同様にDTが56nm, CTが70nmと遡っていきます。

ベンチマーク結果

  • HD Tune Read Test (Full Test)

  • HD Tune Write Test (Full Test)

  • HD Tune Random Write Test


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

JSMonitor

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のままなんでしょう？

(2)JEDECの耐久性基準について

SSD耐久テスト Indilinx篇

JEDECの耐久性基準について

JEDEC(半導体技術協会)は、9月23日にSSDの耐久性と信頼性の計測基準を公開しました(プレスリリース，JESD218(Solid-State Drive (SSD) Requirements and Endurance Test Method)，JESD219(Solid-State Drive (SSD) Endurance Workloads))。この基準では、SSDの耐久性を"TBW(TeraBytes Written)"、すなわち"何TBのデータを書き込めたか"で示そうとするもので、試験の環境や負荷のかけ方が厳格に定義されています。SSDの耐久性や信頼性を示す上でMTBF(平均故障間隔)がほとんど役に立たないことは明白であり、それに変わる有意義な規格を目指しているようです。類似の規格としてはSanDiskが提案したLDEというものがありましたが、既に忘れ去られつつある気がします。
さて、今回の耐久テストについてですが、結論から言うとこの基準には従いません。というか、台数と温度の要件を満たすことが事実上不可能なので、従うことができません。
そもそも、JEDECの基準は、TBWという指標によってSSDの耐久性を格付けするためのもので、目標とするTBWに達するまで書き込みを行い、テスト終了時までに要求された条件が満たされているかどうかを調べるというものです。それに対し、今回のテストは壊れるまで読み書き(+放置)を続け、その内部状態をSMARTで調べてみようという趣旨で行います。若干目指している方向が違うんですね。

JEDECの耐久性評価基準の詳細

そういうわけで、今回のテストとは直接は関係ないのですが、せっかくなのでJEDECの基準の内容を紹介しておきたいと思います。

テスト期間中に満たすべき条件

テスト対象のSSDは、テスト期間中に下記の状態を満たしていなければいけません。

  1. SSDの容量が減っていない
  2. UBER(Uncorrectable Bit Error Rate)が要求値以下である
  3. FFR(Functional Failure Requirement)が要求値以下である
  4. 要求された時間電源を切断されていてもデータが保持されている

UBER, FFR, 電源切断時間のそれぞれの要求値は後述するApplication Classごとに定められています。
UBERとは、読み込み時のデータエラーの数をを読み込んだ総ビット数で割った値です。前回の記事で述べたRBERはECCを行う前のエラーレートですが、こちらはECCで修正しきれなかったエラーレートを表します。HDDのUBERはおよそ1.0E-13〜16(1.25TB〜1.25PBの読み込みあたり1ビット)程度であるようです。
FFRはより単純で、ストレージとしての機能を失ったSSDの割合です。例えばリードオンリーモードになってしまったSSDは、Functional Failureの状態になっていると見なされます。なお、明らかにNVM(NANDフラッシュ)の耐久性との因果がない故障は除外してもよいことになっています。

Application Class

SSDの仕様用途に応じて、"Enterprise"と"Client"の2つのApplication Classが用意されています。前者はサーバなどの用途、後者は一般的なPC用途を示しているようです。

  • Enterpriseクラス

Enterpriseクラスでは、55℃で24時間連続使用が求められ、UBER, FFR, 電源切断時間の要求値はそれぞれ1.0E-16, 3%, 3ヶ月(40℃)となっています。
書き込みパターンはJESD219に定義されており、書き込みサイズとその割合は以下のようになっています。

書き込みサイズ 0.5K 1K 1.5K 2K 2.5K 3K 3.5K 4K 8K 16K 32K 64K
割合 4% 1% 1% 1% 1% 1% 1% 67% 10% 7% 3% 3%

また、書き込みの50%はLBAの最初の5%の部分に、書き込みの30%は次の15%の部分に、書き込みの20%は残りの部分に行います。これは、おそらくウェアレベリングのアルゴリズムがよくないSSDに厳しい評価が出るように、書き込み回数をあえて不均一にするものでしょう。

  • Clientクラス

Clientクラスでは、40℃で1日あたり8時間の使用が求められ、UBER, FFR, 電源切断時間の要求値はそれぞれ1.0E-15, 3%, 1年(30℃)となっています。電源切断時間の要求値はEnterpriseより長くなっています。
なお、現在のところ、Clientクラスの書き込みパターンは開発中であり、公開されていません。

テスト手法・要件

耐久性の検証は、直接的方法(direct method)と補外法(extrapolation method)の二つがあります。直接的方法は、設定されたTBWに達するまで書き込みを行った後、データ保持テストを行います。直接的方法は1000時間行うことを求められていて、それ以上の時間がかかるときは補外法を用いることが許可されています。
テストに用いられる台数は、FFRとUBERの値が60%以上の信頼性となるように設定します。例えばFFRが3%である場合、x台のSSDのうち1台以上壊れる確率yは，y=1-(0.97^x)と表せます。y=0.6のとき、x=log(0.97)/log(0.4)=30.082 となります。従って、yが0.6以上になるxの最小の整数値は31となります。この場合、31台でテストを行って1台も壊れないことが求められます。こんな計算をいちいち行うのは面倒なので、JESD218ではこの最低台数を求めるためのテーブルを使った簡単な計算方法が記載されています。それによると、68台でテストを行った場合は1台までは壊れてもよく、104台でテストを行った場合は2台まで壊れてもよい、ということになるようです。
また、テスト中及びデータ保持期間の両方において、SSDを低温環境と高温環境の両方に置かなければなりません。そのためのテスト方法として、"ramped-temperature approach"と"split-flow approach"の2つがあります。詳細は省略しますが、前者はテスト中に温度を上げ下げする方法で、後者はSSDを半々に分け、片方は高温環境で、残りは低温環境でテストするというものです。よく分からないのが、これらのテストで指定されている温度やデータ保持期間が前述のアプリケーションクラスの数値と違ってる点です。アプリケーションクラスの数値は、こういう環境での使用が要求されてますよってだけで実際のテストとは異なるってことなんでしょうか…？
あとは補外法についてなんですが、そろそろ読むのに疲れて心が折れたので省略させていただきます。そのうち気が向いて残りを読むことがあったら更新するかも？

Firefoxでトラックポイントキーボードの中央ボタンスクロールを有効化する方法 KeySnail版

今日の記事はほとんど個人用の備忘録みたいな内容です。SSDの話題じゃなくてすいません。

僕はThinkpad信者(というかトラックポイント信者)なので、自宅でも大学でもトラックポイントキーボード(55Y9024)を愛用しています。
トラックポイントキーボードは中央ボタンを使ったスクロール機能が付いていてとても便利なのですが、困ったことにこのスクロール機能はデフォルト状態のFirefoxでは使用することができません。中央ボタンを押すと"Ctrl+K"が押されたことになってしまい、フォーカスが検索ボックスに移動してしまうためです。
この問題は、ドライバを最新版にしたりabout:configで"ui.trackpoint_hack"を1にするといった方法で解決できることもあるようです。しかし、自宅(Windows 7 Pro 64bit)と大学(Windows 7 Pro 32bit)の双方とも、これらの方法は無効でした。
そこで、今までは"keyconfig"というアドオンで"Ctrl+K"のショートカットを無効にしていました(詳しくは［組み込みエンジニア］$ 美容と健康、マネーを考える＞＞ブログ さんの記事などを参考にしてください)。しかし、このkeyconfigというアドオンは既に開発が止まっているようで、Firefoxの最近のバージョンでは動作しません。互換性の確認を無効にしても"設定"ボタンがグレイアウトして押せない状態です。
というわけで、keyconfigの代替として"KeySnail"というアドオンを試してみたところうまくいったので、設定方法を下記にメモしておきます。

  1. 作者のWebサイトから、keysnail.xpiをダウンロードし、Firefoxにドラッグ＆ドロップ
  2. "設定ファイルを新しく作成する"を選んで"次へ"をクリック
  3. "キーバインドの設定無し"を選択して"完了"をクリック(Emacs好きな人は他のスキームでもいいかも？)
  4. KeySnailの設定を開き、"キーバインド"を選ぶ
  5. 右下の"追加"をクリック->"組み込みコマンド"を選択
  6. "フォーカスコマンド"->"コンテンツへフォーカス"を選んで"OK"
  7. "キー"欄でCtrl+Kを入力し、"変更の反映"をクリック

Ctrl+Kを無効にするのが目的なので関数の中身は空でもよいのですが、その場合テキストボックスにカーソルがあるときにスクロールができません。しかし、上記のように設定を行うと、中央ボタンを押したときにテキストボックスが選択されていない状態になるので、そのままスクロールができるようになるという寸法です。
しかしこれでも時々テキストボックス選択時からのスクロールがうまくいかないことがあります。特にiGoogleで顕著なのですが、あまりFirefoxについて詳しくないので原因はさっぱり分かりません。どなたか分かる方いらっしゃいませんか？