(5) ファームウェア1916で全ての問題が解決？
SolidataのK5-64にファームウェア1916を適用してから約10日が経過しました。現在のJSMonitorの状況と、CrystalDiskMarkの結果は以下の通りです。
*1
Maximum Erase CountとAverage Erase Countの差は不気味なまでに256を保ち続けています。また、1819〜1881では80MB/s程度まで書き込み速度が低下してしまう症状がありましたが、それも修正されています。さらに、ファームウェア1881を適用したときはファイルが消えたりWindowsが立ち上がらなくなったりとひどい目に遭わされたのですが、1916ではこれまでのところ特に問題はありません。
というわけで、ようやく安心できそうな状態になりました。1916相当のファームウェアは、既にOCZ, Super Talent, Crucialでも公開されています。
ちなみに、10日前はテック社のサポートページから普通にファームウェアアップデータがダウンロードできる状態だったのですが、現在は問い合わせが必要になったようです。Solidata本社のサポートページでも、ダウンロードにはIDとパスワードが必要になっています。やはり他のSSDにも適用できるようなプログラムを無制限に配るのはどうよ、って話になったんでしょうか？
*1:JSMonitorの表示が公開版と違うのは微妙にアップデート作業中だからです
Samsung PB-22J 新ファームウェアのベンチマーク
前回の記事で述べたとおり、Samsung社製コントローラ搭載SSD(PB-22Jシリーズ相当)のファームウェアがアップデートされました。正確なリリースノートは公開されていないようですが、Trimに対応したことが目玉となっています。今回は、MasterDrive SX(PB-22Jシリーズ相当)の64GB版を最新ファームウェアにアップデートし、ベンチマークを行ってみました。
まずはCrystalDiskMakr 3.0 Beta2から。これらのテスト結果には再現性があり、何度やってもほぼ同等の結果が得られます。
- テストサイズを1000MBにするとランダムライトの結果が落ち込む
- ランダムライト4Kの結果は、いずれも最初の1回目のもの。2回目以降はQD32のテストと同程度の性能しか出ない
- NCQが全く効いていない
1つめの特徴は、JMF602やMTRONといった旧世代のSSDと同じです。すなわち、SSD内の予備領域の一部をあたかもキャッシュのように用いているため、そこからデータが溢れるとパフォーマンスが下がってしまうというものです(詳細はこちら)。おそらく、その領域の大きさが1GBより小さいのでしょう。
2つめの特徴は、おそらくDRAMキャッシュのためでしょう。4Kの書き込みにしか効いていないのは、大きな書き込みをキャッシュするとあっという間にバッファが埋まってしまうため、ある程度のサイズ以上の書き込みはキャッシュを通さずに直接NANDに書き込むような仕組みがあるからだと思われます。
3つめはもう残念ですとしかいいようがありません…
次に、Iometerを用い、ランダムライトによって性能低下が引き起こされるかどうかを計測してみました。1分の1MBシーケンシャルライト→30分の4KBランダムライト(正確には1分x30回)→1分の1MBシーケンシャルライトというテストパターンによる計測です。
結果は、最初のシーケンシャルライトが140.16MB/s、2回目のシーケンシャルライトが134.72MB/sと、ほとんど性能低下が発生しませんでした。
まとめと考察
CrystalDiskMarkの結果を見る限り、このシリーズは、旧世代のSSDにDRAMキャッシュを乗せただけのように感じられます。これならMTRONやJMF602のように、性能低下はあまり起こらないのではないかと予想されます。実際に、Iometerのテストではほとんど性能低下が発生していません。このIometerのテストではTrimが送信されることはないため、Trimによる性能回復が起こっているわけではありません。
しかし、例えばPC Perspectiveの記事やAnandTechの記事では性能低下が報告されているので、もしかすると新ファームウェアでは挙動が変化したのかもしれません。
なお、こちらの環境では、HD TuneやIometerでパーティションの無い状態でのテストを行うと、シーケンシャルライトの結果が50〜70MB/s程度しか出ず、正確な測定ができません。HD Tuneの方は4.0で導入された"Full Test"のオプションを有効にしているので完全なシーケンシャルライトになっている筈なんですが… しかもHD TachはWindows 7では動きません。
いずれにしても、このSSDはパフォーマンス面であまり期待できないのは間違いありません。ノートPCに搭載された実績が多いという面で多少安心感はありますが、それなら東芝を選んだ方がいいような予感もします。
各社新ファームウェア公開＋Sandforce製新コントローラ搭載SSDの情報
Samsung社製コントローラの新ファームウェア
Samsung社製コントローラ搭載SSD(PB-22Jシリーズ相当)用のファームウェアアップデートツールがようやく公開されました。Corsair P-Series用、OCZ Summit シリーズ用、Super Talent MasterDrive SX用がそれぞれダウンロード可能です。ファームウェアアップデート時にはデータが消去されるようですので、注意してください。
このアップデートにより、Samsungコントローラ搭載SSDもTrimに対応しました。なお、ファームウェアバージョン18C1,1901で実装されていたAuto-Trim(アイドル時に性能を自動的に回復する機能)が有効になっているかどうかは、今のところ情報がなく不明です。
Indilinx社製コントローラの新ファームウェア
Indilinx社製Barefootコントローラ用のファームウェアに関しても、バージョン1848, 1881の2つの新バージョンが公開されています。前者はA-DATA S592シリーズ用、後者はSolidata K5/K6シリーズ用です。後者はMP Toolとして公開されているので、ジャンパを搭載している他のSSDをアップデートできる可能性があります。
ファームウェアの更新内容は、リリースノートがどちらのメーカからも公開されていないので謎です。分かる限りでは、Power Cycle Countが更新されなくなっていたバグがバージョン1881で修正されています。
S592シリーズは安価なことから人気がありましたが、長らくファームウェアが提供されていませんした。今回のアップデートにより、ようやく他社製品と同等の状態となりました。ただし、64GB版はアップデートに失敗し、ディスクが認識できなくなる例が相次いでいます。どうやらアップデータがDRAM32MBの製品に対応していない可能性があるようです。なお、この現象によりディスクが認識できなくなった場合、保証が効くようですので、購入店に問い合わせてみてください。
S592の古いバージョンのファームウェア(1279)では、SMARTの仕様が現在とは異なっているようで、JSMonitorではAverage Erase Countが非常に大きな数値に表示されます。JSMonitorをS592でお使いの方は、ファームウェアをアップデートすることを推奨します。そのときは、アップデート前にログをいったん消去してください。
Intel SSD Toolbox
IntelのSSD Toolboxはいつの間にか公開が停止されていたのですが、このページからダウンロード可能になっています。リリースノートを見る限り大きな変更はないようですが、SSD Toolboxをお使いの方はアップデートしておきましょう。
Sandforce社製コントローラ搭載SSDのベンチマーク
Sandforceというアメリカの会社が、新たにコンシュマー向けSSDコントローラ市場に参入するようです。すでに、OCZ,A-DATA,Photofastから同社製品を搭載したSSDがアナウンスされています。
エルミタージュ秋葉原の記事ではいち早くベンチマーク結果が公開されています。CrystalDiskMarkのRandom Write 4Kの性能がIntel並みに高く、期待が持てます。よく分からないのがシーケンシャルライトの性能で、東芝同様にCrystalDiskMarkのテストサイズを増やすと性能が向上しています。また、ATTOではそれよりさらに高い性能となっていて、かなり謎度が高いです。
(4) やっぱりバグ直ってない疑惑＆Solidata K5-64の書き込み速度低下について
前回の記事で、Barefoot用ファームウェア1819においてMaximum Erase Countが異常に多くなるバグが修正された模様であると書きましたが、どうやら完全には直っていなかったようです。
一時的にVertexの30GBモデル(ファームウェア1.4)をシステムドライブとして使用していたのですが、気がついたときには下図のような状態になっていました。
11月中はMaximum Erase Countに全く変化が無かったのですが、12月6日以降は使えば使うほどAverageとMaximumの差が開いています。他のJSMonitorのユーザの方からも、同様にファームウェア1819にアップデートしたSSDにおいてMaximum Erase Countが突然急上昇を始めたという報告をいただいています。
そういう訳で、この問題に関するファームウェア1819のバグフィックスは完全ではなかったようです。
さらに、1.4/1819にアップデート後Power Cycle Countが更新されなくなっていたことに(今さら)気がつきました。まあこれは特に大きな問題ではないのですが…
次に、この記事で、1819にアップデートしたK5-64を使っていると書き込み速度が低下してしまったことを報告しましたが、その件についての続報です。
Solidataの輸入代理店のテック社のサポートページに、K5シリーズ用の正式なファームウェアが公開されたので、こちらを使って再度手持ちのK5-64のアップデートを行いました。このページには"1819"と"1819GC"の2つのバージョンが公開されていますが、おそらくそれぞれがVertexシリーズの1.4と1.41に該当するものだと思われます。
1819GC版のアップデータはマニュアルが公開されていませんが、アップデート方法はVertexシリーズの初期ファームウェアと同様です。ジャンパを付けたSSDを接続し、Windows上で"start.exe"を実行するだけでアップデートが完了します。ちなみに、このプログラムでアップデートを行うと、ドライブ名が"INDILINX BAREFOOT-SATA"になってしまうようです。
結論から言うと、この問題は上記の正式な1819、1819GCのどちらのファームウェアを用いても発生しています。パーティションを復元してしばらくはシーケンシャルで160〜180MB/s程度の書き込み速度が出るものの、しばらく使用していると70〜80MB/sにまで落ち込んでしまいます。
その状態でパーティションを削除してHD TuneでWrite Test(8MB, Most Accurate)を行った結果が以下です。
ディスク全体の書き込み速度が平均80MB/s程度にまで下がってしまっています。この状態は、sanitary_erase.exeを用いれば修正できますが、wiper.exeやTrimは効果がありません。すなわち、データが存在する状態では性能を元に戻せません。
やはり今のところこの問題の解決策と原因は分かりません。起動ドライブとして使う分には体感の差はあまりないのですが、SLCの利点の一つは書き込み速度の速さにあるので、この問題はちょっと気になってしまいます。
(3) ファームウェア1819におけるウェアレベリングの性能
今まで、Indilinx社製Barefootコントローラを搭載したSSDを使っていると、特に異常な操作をした訳でもないのにMaximum Erase Countが非常に大きな値となる現象が発生していました。
結論から言うと、どうやらこの現象はファームウェアのバグに起因するものであったようで、バージョン1819(Vertex 1.4/1.41, Agility 1.3/1.31)では修正されました。以下では、その問題について、Solidata製のK5-64を用いた検証の結果について記します。
ファームウェア1819のリリースノートには、このような一文があります。
- Bug fix: Performance boost routine reused the recently used block and it did harm to wear leveling.
あからさまに怪しいです。すぐにこの問題の検証をしたかったのですが、こちらの手持ちのVertexはすでにMaximum Erase Countが3300を超えており、この値が更新されるまで書き込みのテストを行うのは気が引けます。しかし、前回の記事に書いたとおり、MP Toolを用いてファームウェアをアップデートすると、SMARTの値を含むSSD上の全てのデータがリセットされます。そこで、K5-64をMP Toolでアップデートし、Average/Maximum Erase Countがほとんど0に近い状態で検証を行いました。
検証内容は、LBA上の同じアドレスにデータを書き込み続け、その時のAverage/Maximum Erase CountをSMARTから取得するというものです。スタティックウェアレベリングのアルゴリズムが悪いと、このテストによってMaximum Erase Countだけが増え続けてしまいます。
以下に、ファームウェア1571の時のテストを再掲します。縦軸にMaximum Erase Count、横軸に書き込み回数を取ったグラフが以下です。
テスト内容を若干変更して4回計測しましたが、いずれも8500〜9000回の書き込みでMaximum Erase Countが600を超えています。
これと同じテストをファームウェア1819において実行しました。スタート時のMaximum Erase Countは33，Average Erase Countは19でした。
…Maximum Erase Countは全然上昇しません。2871回目の書き込みで先にAverage Erase Countが20になり、その後、10220回目の書き込みでようやくMaximum Erase Countが34になりました。これではグラフを作るまでもありません。
というわけで、この問題はバグに起因しており、ファームウェア1819で修正されたと考えるのが妥当です。もしかすると、Barefoot搭載SSDの故障が多い(気がする)のも、この問題が原因かもしれません。というわけで、未だに1571以前のファームウェアをお使いの方は、できる限り早急に1819にアップデートすることをおすすめします。
なお、以下が現在のJSMonitorの結果です。
Maximum PE Count Specificationが10,000だったのも、ちゃんと100,000に直っていました。
G-Monster 1.8 V3用のMP ToolでSolidata K5-64をファームウェア1819にアップデート
Photofastのダウンロードページに、G-Monster 1.8 V3用のMP Tool(現在リンク切れ：2009/11/21確認)が公開されています。Solidataがいつまでたってもバージョン1819のファームウェアアップデータを公開してくれないので、これを使って恐る恐るK5-64のアップデートに挑戦してみました。
一応おことわりしておきますが、以下に述べるアップデートはおそらく動作保証外の行為です。試してみる場合は、SSDが故障しても泣かない覚悟を持ち、自己責任でお願いします。
以前の記事で紹介したとおり、MP Toolはジャンパを接続した状態のIndilinx SSDのファームウェアをアップデートするプログラムです。OCZなどが公開しているアップデータと異なり、Windows上で動作します。なお、MP Toolでファームウェアをアップデートすると、データはおろかSMARTの値まで初期化されてしまいます。
K5-64はWindows 7(64bit)マシンで使用しているのですが、どうもこのマシン上ではMP Toolの挙動が怪しく、Loadボタンを押すとプログラムが落ちたりします。とてもこのままファームウェアアップデートに踏み切る勇気が出なかったので、わざわざWindows XP(32bit)、AMD790GX(IDEモード)の旧マシンに接続し直してアップデートを行いました。
アップデートの手順は以前の記事に記したのとほぼ同じですが、Auto Detectionでは認識ができませんでした。そこで、手動で"SAMSUNG K9WBG08U1M 64GB(SDRAM 64MB)"を選択して実行したところ、うまくいきました。
次に、アップデートし終わったK5-64をWindows 7マシンに戻し、以前の記事と同じ方法で、Trimの効果を調べてみました。
アップデート直後のHD TuneのWriteテスト(TestSize=8MB,Most Accurate)の結果が以下です。
そのままIometerで4KBのランダムライトを30分行った結果が以下です。
Trimを送信するためにパーティションを作成し、すぐにそのパーティションを消去してもう一度HD Tuneのテストを行った結果が以下です。
何か怪しげですが、一応性能は回復しています。Trimは効果を発揮していると言ってよいでしょう。
以上、ようやく念願かなってK5-64をファームウェア1819にアップデートすることができました。予定通りSMARTの値はリセットされたので、以前から気になっていたMaximum Erase Countが急上昇する問題を再度調べてみたいと思います。
追記(2009/11/21更新)
この記事を書いた頃にはPhotofastのダウンロードページからMP Toolをダウンロードできたのですが、現在はリンク切れになっています。ファイルを取り下げた理由は記載されていなかったのですが、何らかの問題があった可能性もあります。
こちらでは、書き込みのパフォーマンスが大幅に下がるという現象が発生しています。
ファームウェアアップデート後にディスクイメージをTrueImageで復元し、すぐに計測した結果が以下です。
しかし、現在の性能は以下のようになっており、ライトが70MB/s程度しか出ません。
AS SSD Benchmarkなど、他のベンチマークでもほぼ同じ結果になります。wiper.exeを使用しても、Iometerで空き領域いっぱいにファイルを作成して削除(これで空き領域すべてにTrimを送れます)しても、結果は変わりませんでした。
また、別パーティションからOSを起動し、sanitary_eraseでいったんSSDを初期化してTrueImageでOSを復元したところ、一時的に性能が回復しましたが、現在ではまた2枚目のスクリーンショットとほぼ同等の性能の性能に落ち込んでいます。
なお、Indilinxコントローラ搭載SSDの場合、物理アドレスの断片化による性能低下が生じると、書き込みだけでなく読み込み速度も低下します。上記のスクリーンショットの結果を見る限り読み込みの性能はほぼ変わっていないため、おそらく今回の現象は別の原因で生じていると考えられます。今のところ対策は分かりません…
Windows 7のSSD対応に関するまとめ
今回の記事では、Windows 7のSSD対応の内容についてまとめておきます。
Windows 7がどのようにSSDを認識するのか、SSDと認識されたドライブに対して何が行われるかについては、"Engineering Windows 7"Blogの日本語翻訳版の記事に詳しく記されています。
それによると、Windows 7は以下の2通りの方法でSSDを認識しているようです。
- IDENTIFY DEVICE dataのWord 217の値が1 (参考:ATA8-ACS仕様書)
- ランダムリード性能が8MB/s以上
前者の条件を満たすSSDは、CrystalDiskInfoで"回転数"の項目が"----(SSD)"と表示されます。この規格は策定されたのがつい最近であり、やや古いSSDでは対応していません。そのため、後者の条件を付け加えることにより、すべてのSSDを正しく認識できるようにしているということです。
この機能によってSSDと認識されたストレージ上のドライブは、スケジュールデフラグの対象外となります。
また、システムドライブがSSD上にある場合、Superfetch、起動プリフェッチ、アプリケーション起動プリフェッチ、ReadyBoost、ReadyDriveがすべて無効になります。よって、SSDがOSから正しく認識されていれば、Vista以前のOSのように、手動でSuperfetchやPrefetchの設定をする必要はありません。*1
ただし、ランダムライトのパフォーマンスが低いSSDについては、それらの機能オフが無効になるということです。おそらく具体的な対象はPhison製コントローラとJMF601/602なのでしょうが、どうやらプチフリ中は読み込みも止まってしまうため、メモリに置いておいた方がいいよ、ということのようです。
実際のところは？
Windows 7 Professional 64bitのマシンに、以下のストレージを接続して確かめてみました。
- Cドライブ: Solidata K5-64 (SSD, Word 217=1)
- Eドライブ: WesternDigital WD6400AAKS (HDD)
- Fドライブ: OCZ Vertex 30GB (SSD, Word 217=1)
- Hドライブ: Buffalo SHD-NSUM30 (SSD, Word 217=0)
スタートメニュー→アクセサリ→システム ツール→ディスク デフラグ ツール を実行すると、以下のような画面が現れます。
すべてのドライブが表示されていますが、この画面は手動でのデフラグを実行するための画面なので、この状態でOKです。PC Watchの元麻布さんの記事では、この画面でCドライブが表示されていることから"X25MをSSDとして認識しなかった"と書いてありますが、これは勘違いの可能性が高いです。スケジュールデフラグの対象になっているドライブを表示するには、この画面から「スケジュールの有効化」または「スケジュールの構成」ボタンを押し、次のウィンドウでさらに「ディスクの選択」ボタンを押します(このボタンを押すためには、「スケジュールに従って実行する」チェックボックスにチェックを入れる必要があります)。
Eドライブ(HDD上),Hドライブ(Word 217=0のSSD上)のみ一覧に現れています。実際に、タスクスケジューラからScheduledDefragを手動実行すると、「ディスク デフラグ ツール」画面の「最後の実行」の時刻がE,Hドライブのみ更新されます。
上記のスクリーンショットから分かるように、こちらの環境では、JMF602搭載SSDはSSDとして認識されていないようです。このドライブは4KBのランダムリードで約15MB/s程度の性能は持っているので、前述のSSD認識条件の2番目は満たしているはずです。それにも関わらずスケジュールデフラグの対象になっている原因は不明です。他にもSSDの認識に失敗する例はあるようなので、何か認識のアルゴリズムに問題がある可能性もあります。
Prefetchが有効かどうかは、C:\Windows\Prefetchフォルダにファイルが作られているかどうかで調べることができます。また、Superfetchはサービスの一つなので、コントロールパネル→管理ツール→サービスで状態を確認することができます。"Superfetch"というサービスの「状態」が「開始」ではなく空白になっていれば、Superfetchは無効になっています。
- 補足
Intelの天野氏の講演の記事に、SuperFetchの状態が変化する条件が掲載されていたので、下記に引用します。
データを先読みする「SuperFetch」も、わざわざオンにする必要はないと解説。もっとも、「Windowsエクスペリエンス インデックスの値が5.9以下だと多分HDDだろう、逆に6.5以上だと多分SSDだろうとコンピューターが判断し、自動でオンオフしてくれる」という。
Trimの有効・無効の確認
以下の方法により、現在のシステムでTrim送信機能が有効か無効かを確認できます。なお、後述するように、通常の場合、ユーザーはこの設定について変更を行う必要はありません。
- "Windowsキー+R"を押し、"cmd"と入力してEnter
- "fsutil behavior query DisableDeleteNotify"と入力してEnter
- "DisableDeleteNotify = 0"と表示されればTrim有効、"DisableDeleteNotify = 1"と表示されれば無効
分かりにくいのですが、コンピュータ(というかプログラミング)の世界では0は"false(偽)"を表すので、Disableがfalse = Enableとなっているわけです。
DisableDeleteNotifyの値は、ストレージがTrimをサポートしているかどうかとは無関係で、OS側がTrimを送るかどうかの設定を表します。デフォルト設定は"DisableDeleteNotify = 0"なので、この設定のままで問題ありません。また、ストレージがTrimに対応するかどうかに応じてOSがこの値を勝手に変更することはありません。
そういうわけで、こちらもPC Watchの元麻布さんの記事なのですが、これには2重に勘違いがあります。返ってくる値は0で正しく、しかもIntelのSSDがSSDと認識されているかどうかはこの件とは関係ありません。
なお、テスト目的などでTrimを無効にしたい場合は、"fsutil behavior set DisableDeleteNotify 1"と入力してEnterを押します。有効に戻す場合は1を0に変えればOKです。
- 補足
上記はあくまで"Windows 7がTrimを送信している"ことを示しているのみです。大変不便なことに、SSDがTrimを正しく受け取っているかどうかを簡単に確かめる方法は(現在のところ)ありません。手間がかかっても良いからどうしても確かめたいという場合は、この記事を参考にしてください。
SSDがTrimを正しく受け取れない例としては、古いバージョンのAHCI用ドライバがインストールされている場合や、RAIDを構成している場合が挙げられます。
現在のところ、確実にTrimに対応しているドライバは、以下の通りとなります（2011年5月現在)。
- Microsoftの標準AHCIドライバ
- Intel Rapid Storage Technology (全バージョン) DL
- Marvell SATA3チップ(88SE9123/88SE9128)用AHCIドライバ(バージョン1.0.0.1051以降) DL
- AMDチップセット用AHCIドライバ(バージョン1.2.1.275以降) DL
また、一時期IRSTではRAIDを構成するSSDにもTrimが送信されるという情報がありましたが、どうやらそれは誤報のようです。正しくは、「BIOSがRAIDモードになっている状態で、RAIDを構成していないドライブに対してTrimが送信される」とのことです。
AMDやMarvellでRAIDを構成した場合については、情報が見つかりませんでした。
*1:この記事の初出時、SuperfetchやPrefetchがドライブごとに有効・無効となるという旨の記述をしていましたが、それは間違いでした。申し訳ありません。
