2012年12月4日火曜日

Deterministic Zeroing TRIMについて

前回の記事では、Trimコマンドの送信を個人で確認する方法ついて説明しました。
気がつくと、数ヶ月かけてTrimがらみの記事を4連発ということになりますが、今回は、前回の記事の補足としてTrimコマンドを受け取ったあとのSSDの動作について、もう少し、突っ込んで説明したいと思います。

Trimコマンドによって取得した論理アドレスに対して、書き込みが発生する前に、読み出しが発生した場合の動作の方法がSSDには2つ準備されています。1つが、前回の記事でも書いた「Read Zero After Trim(以下、RZAT)」。もう1つが、「Deterministic Read After Trim(以下、DRAT)」です。

前者のRZATとは、上記の条件のもとでは文字通りデータとして「0」を返すという仕様です。非対応のSSDは、その時点に書き込まれているデータを対応する物理アドレスから読み出してOSに返します。この場合の動作は、HDDと同じです。

一方、後者のDRATは、上記の条件の場合に必ず同じデータが返ってくることを保証する機能です。この機能に対応したSSDは、Trimコマンドによって取得した論理アドレスに対して書き込みが発生しなければ、必ず同じデータが返ってきますが、非対応の製品は、それが保証されません。

なぜDRATが準備されているかといいますと、SSDでは、Trimコマンドによって取得した論理アドレスのデータの内容が書き込み発生前に変わってしまう可能性があるからです。たとえば、Trimコマンドを受け取った直後は、物理消去ができなくてもGCの発動によって物理消去可能となるケースが考えられます。

この場合、Trimコマンドを受け取った直後のデータは、Trimコマンドを受けとる前と同じです。しかし、物理消去が実行されてしまうとデータの内容は、Trimコマンドを受け取った直後とは異なることになります。つまり、DRAT非対応のSSDでは、Trimコマンドで受け取った論理アドレスのデータが変わってしまう可能性がある(不確定である)ことを示しています。

「不要なデータだからどちらでも良いのでは」と考えられる方もいる思いますが、これは、RAID5/RAID6などの環境においては重要なことです。RAID5やRAID6では、パリティを書き込みますが、ファイルシステム上で削除したデータもそのまま変更されずに残っていることが前提となってパリティが作成されているからです。

しかし、Trimコマンドでは、受け取ったアドレスをどのように利用するかの規定はなく、SSD側が、受け取った情報を自由に利用できます。このため、TrimコマンドによってSSD側で勝手に物理消去が実行されてしまうと、Trimコマンドを受け取った直後と多少時間がたってからでデータの内容が異なってしまうケースがでてきます。これは、RAID5やRAID6にとって非常に都合が悪いということになります。そこで準備されたのが、Trim後もそのアドレスに対して書き込みが発生しなければ、常に同じデータが返ってくることを保証するDRATです。

DRATは、当初ほとんどのSSDが対応していませんでした。Trimで送られてきた論理アドレスのデータを次回書き込みが発生するまで常に同じにしたいなら、Trimコマンド非対応またはTrimコマンドを送らなければよいからです。ですが、これでは、せっかくのTrimコマンドのメリットが全く生かされません。

そこで登場するのが、現在実装が進む「Deterministic Zeroing TRIM」です。これは、Trimコマンドによって取得した論理アドレスに対して、書き込みが発生する前に、読み出しが発生した場合、いついかなる時も必ず「0」を返すという仕様です。この仕様でいけば、ファイルシステム上で削除フラグがたったファイルのデータは常に「0」であるものとしてRAID5/6環境で運用できます。これによって、前述の不都合が解消できるというわけです。

もう少し詳しくDeterministic Zeroing TRIMについて説明します。Deterministic Zeroing TRIMを実装する場合、「0」を返すのは、コントローラーの仕事であってTrimコマンドで送られてきた論理アドレスが、実際に物理消去されているかどうかは関係ありません。これは、Trimコマンドによって受け取った論理アド レスすべてが即時消去を行えるわけではないからです。

NANDメモリの書き込み/読みだしの物理単位はペー ジと呼ばれ、現在のSSDなら8KB程度だと思います。一方、消去は、ページを複数個(128個とか256個)まとめたブロックと呼ばれる単位で行われます。さらに、Trimコマンドで送られてくるのは、論理アドレスですから、512バイト単位ということになります。

これからもわかるように実際の運用においてTrimコマンドで送られてきた論理アドレスが、そう都合よく消去できるわけではないということが容易に想像できます。Windowsは、4KB以下のファイルのアクセスが大半を占めるので、漏れが生じるのは明らかだからです。

このため、Deterministic Zeroing TRIMでは、以下のような流れで処理を行なっていると推測されます。
  1. Trimコマンドを受け取る
  2. SSD内部の管理テーブルにTrimコマンドで送られてきた論理アドレスを登録(フラグを立て)しする。
  3. 読み出しが発生する。
  4. フラグが立てられた論理アドレスだった場合、コントローラが自動的に「0」を返す。それ以外の場合は、通常の読み出しを行いデータを返す。
Deterministic Zeroing TRIMでは、書き込みが発生しない限り、Trimコマンドで通知された論理アドレスのデータは、いついかなる時も必ず「0」で返さなければなりません。これを実現するには、上記のような仕組みの実装が事実上必須だといえます。

ここでまで読んで、あることに気づかれた思われた方がいるのではないでしょうか。そうです。Read Zero After TrimとDeterministic Zeroing TRIMでなにが違うのかということです。
正直、僕も違いがわかりません。

というのも、RZATやDRATの対応、非対応の確認は、ATA IDENTIFY DEVICEコマンドで取得できる情報のWord69、Bit5/Bit14で確認できます。Bit5は、RZATのフラグで、Bit14がDRATのフラグです。それぞれ、「1」がセットされていた場合は対応。「0」の場合は非対応です。

Deterministic Zeroing TRIM用のフラグは準備されていませんので、普通に考えれば、RZATおよびDRATの両方に「1」をセットしておけば、Deterministic Zeroing TRIM対応と考えることができます。このタイプ製品は、僕の知る限り現状、SAMSUNG 840/840Proに加え、Intel SSD 320シリーズがあります。


しかし、Intelの330/335/520シリーズやMicron/CrucialのSSDのように、DRATにのみ「1」がセットされ、RZATは「0(非対応)」となっていますが、データとしては「0」を返してくるような製品もあります。また、Plextor(PLDS)のSSDは、DRAT/RZATの両方に「0」をセットしつつ、実際にはデータとして「0」を返してきます。


前者の場合は、DRATが「1」となっている上で、データとして「0」を返してきているので事実上、Deterministic Zeroing TRIM対応ではないかと思うのですが、なんとも言えません。一方、後者の場合は、DRATが「0」となっていますので、「0」が返ってこないケースがごくまれにあるのかもしれません。だからDRATに「0」がセットしてあると見ることもできます。ちなみに、RZATのみが「1」にセットされた製品を僕は見たことがありません。

というわけで、現状では、実際の動作とセットでみると、ATA IDENTIFY DEVICEコマンドで取得できる情報のフラグの立て方に、メーカー間の解釈の違いが存在しているようにみうけられます。コマンドセット場合、手取り足取りこうしろと細かく規定されているんじゃないかと思われる方が多いと思います。しかし、実際は、結構いい加減です。解釈の違いでフラグの立て方が違うとか、コマンドの挙動が他のメーカーと違うとかいうことは、無いわけではありません。今回のIntel/Micronのケースは、これに当てはまるのではないかと推測しております。

なお、RZAT/DRAT対応/非対応の確認は、Intel SSD Toolboxを使うと簡単です。個人的に調べた結果を掲載しておきますので、参考にしていただけたらと思います。

ModelRZATDRAT実データ
Intel 330/335/520×0データ
Crucial m4×0データ
TOSHIBA THNSNSXXXGBSP(砂芝)××読み出したデータ
SAMSUNG 840/840 Pro0データ
SAMSUNG 830××0データ
Plextor M3P/M5P××0データ

2012年11月19日月曜日

Trimコマンドの送信を個人でチェックする方法

前回の記事から随分と時間が空いてしまって申し訳ございません。
今回は、RAID0環境またはそれ以外の環境で、Trimコマンドがきちんと送信されているかどうかを個人で検証する方法について説明したいと思います。

前回の記事は、Windows環境におけるTrimコマンドの送信可否についてレポートしました。現状でわかっていることをまとめるとWindows環境でのTrimコマンドの送信は以下の条件を満たしている場合に限定されます(専用ソフト等を使用したTrimコマンドの送信は含みません。あくまでOSの機能として実装されている場合のみを前提としています)。
  1.  Windows7以降でMSの標準ドライバー(IDE/AHCI)を利用している場合
  2. AHCIモードでTrim対応のベンダードライバー(Intelチップセットの場合はIntel製ドライバー、AMDやMarvellなども同様)を利用している場合(OSは、Windows 7以降に限る)
  3. Intel製チップセット搭載マザーを利用し、かつRAIDモードで利用している場合で、RAID構築に利用していないドライブ(OSは、Windows 7以降に限る)
  4.  Intel 7シリーズチップセットを採用したマザーボードにおいてRAID0を構築している場合で、かつVer11以降のIntel製ドライバーを利用している場合(OSは、Windows 7以降で、IntelのV11以降のドライバーならV11.0.XXXXでも送信されることをバスアナで確認しています)
上記の條件が、僕個人として、現在確認ができているWindows環境におけるTrimコマンドの送信条件です。しかし、ネット上の書き込み等をみると、RAID0で利用している場合のTrimコマンドの送信条件を勘違いしている方がいまだに多いようです。

今回の記事は、これを是正したいということもあり、執筆することにしました。
ここで説明する方法でチェックすれば、単体でSSDを利用している場合だけでなく、RAID0で利用している場合でもTrimコマンドが送信されているかを簡単にチェックできます。興味がある方は、ご自分でチェックを行われることをオススメします。

Trimコマンドが送信されているかどうかの検証は、以下の環境があれば行えます。
  • Windows 7以降
  • ファイル復元ソフト
  • Read Zero After Trim対応SSDまたはそれに準ずる機能を搭載したSSD(詳細は後述)
また、確認手順は、以下の通りです。ごみ箱から削除したファイルをファイル復元ソフトで復元し、そのファイルの内容をするだけという簡単な内容です。復元したファイルが「0」で埋まっ ていれば、Trimコマンドが送信されています。逆に正常にファイルを復元できた場合は、Trimコマンドが送信されていません。
  1. ファイルをごみ箱にドラッグ&ドロップする
  2. こび箱を空にする(ごみ箱からファイルを削除する
  3. ファイル復元ソフトでごみ箱から削除したファイルを復元する
  4. 復元したファイルが「0」で埋まっているかどうかを確認する
なぜ、この方法で確認できるかと言いますと、現在発売中のSSDは、一部の製品を除き、TrimコマンドによってOS側から受け取った論理アドレス(LBA)に対して、書き込みが発生する前に読み出しが発生すると「0」を返す仕様のSSDが主流となってきているからです。このような仕様を、俗にRead Zero After TrimやDeterministic Zeroing TRIM(条件付き)と呼びます。

Windows 7以降では、ごみ箱からファイルを削除すると、OS(Windows)が削除したファイルが書き込まれていた論理アドレスをTrimコマンドでSSDに通知します。しかし、ファイルシステムレベルでは、ごみ箱から削除してもそのファイルに削除フラグを立てるだけで、削除されたファイルが書き込まれていた場所(論理アドレス)の情報は残っています。これより、ファイル復元ソフトを利用すれば、ごみ箱から削除したファイルを復元できます。

しかし、前述した仕様のSSDは、Trimコマンドで送られてきた論理アドレスに対して、書き込みが発生する前に読み出しが発生すると、そのアドレスのデータは、すべて「0」が返ってきます。このため、ファイルの復元そのものは問題なくできますが、中身のデータはすべて「0」になるというわけです。これは、単体で利用していようが、RAID0構成に利用されていようが結果は同じです。

実際の結果をお見せします。
以下の画面は、Read Zero After TrimおよびDeterministic Zeroing TRIM対応のSAMSUNG SSD 840とSAMSUNG SSD 840 Proを使ってRAID0を構築し、ごみ箱から削除したファイルを復元したときの結果です。検証に利用した環境は以下の通りです。
  • マザーボード:Gigabyte Z77MX-D3H Rev1.0(Intel Z77Express採用)
  • RAIDのOROMのバージョン:11.1.0.1413
  • ドライバーのバージョン:11.5.0.1207
  • ファイル復元ソフト:FINALDATA10

これをみてもお分かりのように、ファイルはすべて「0」で埋まっています。いうまでもなく、これは、Read Zero After Trimによって、Trimコマンドで送られた論理アドレスのデータが「0」となるからです。ちなみに、OS側のTrim送信をオフに設定すると、以下のようになり、正常なファイルが復元されます。


このようにTrimコマンドがきちんと送信されているかどうかは、必要な機器さえ揃っていれば、個人でも簡単に確認できます。ただし、この検証を行うには、前述したようにRead Zero After Trim対応SSDまたはそれに準ずる機能を搭載したSSDを利用することが必須です。この条件を満たしていない場合は、Trimコマンドが送られていても正常にファイルが復元されてしまい、本当にコマンドが送られているかを確認できません。

僕が個人的に確認している上記仕様のSSDは、Crucial m4、Plextor M3P/M5P、Intel 320/520、SAMSUNG 830/840シリーズのみです。Sandforce製コントローラを採用した製品は、Intel製SSDぐらいしか「0」を返してくれないので注意してください。

2012年8月30日木曜日

WindowsにおけるTrimサポートのまとめ

先日、原稿でWindows 7を利用した場合のTrim送信環境について、調査する機会がありました。前回のバスアナの記事でも予告したように、今回は、Trimの送信環境についてレポートしたいと思います。

最初にどのようにしてTrimが送信されるかを調査したかを簡単に説明しておきます。Trim送信環境の調査は、前回の記事で書いたプロトコルアナライザ(バスアナ)を利用して行なっています。OSからSSDに送られるATAコマンドをSATAのバス上でキャプチャして、Trimコマンドの送信の有無をチェックしています。Trimコマンドによる効果があるかどうかを検証したわけではありません。Trimコマンドの送信の事実のみをチェックしています。

それでは結果を報告します。

SATAの動作モードは、IDEモード/AHCIモード/RAIDモードのすべてのモードにおいてTrimコマンドの送信を確認しました。これまでのネット上の情報では、Trimの送信はAHCIモードのみという情報がひとり歩きしていましたが、Windows 7/8を利用する限り、IDEモードでもTrimコマンドは間違いなく送信されています。本ブログでは、随分以前にIDEモードでもTrimコマンドがでているという検証結果をレポートしていますが、これがコマンドレベルできちんと確認できました。また、RAIDモード利用時でもRAID構築に利用していないSSDの場合は、問題なくTrimコマンドが送信されます。この点は、以前から知られていた通りです。

加えて、条件付きですが、RAID0の構築に利用されたSSDへのTrimコマンド送信も確認しました。RAID0構築に利用したSSDへのTrimコマンド送信は、海外サイトで紹介されているように Intel 7シリーズチップセットとV11以降のドライバーが必要です。Intelの7シリーズチップセットを採用したマザーボードのOROMのバージョンは、すべてV11以降だと思いますので、OROMのバージョンもV11以降なら問題なくTrimコマンドが送信されると思います。また、Trim送信がサポートされたSSDは、Intel製SSDのみというような制限はないのでご安心ください。Trimコマンド対応のすべてのSSDに対してちゃんと送信されます。

なお、Intel 7シリーズチップセットのRAID環境でTrim送信がサポートされているのは、RAID0構築時のみです。RAID1やRAID5では、Trimコマンドは送信されません

次にいつTrimコマンドが送信されるかですが、これもこれまで一般に知られていた通りです。具体的には、ごみ箱からファイルやフォルダーを削除した場合、フォーマットを行った場合です。パーティションの作成のみでもTrimコマンドは送信されますが、送信されるアドレス情報は非常に少なく、無視して良い程度のものです。

更にSSDをHDDのキャッシュに利用すると「SRT(Smart Response Technology)」利用時もチェックしてみましたが、こちらは、SRT設定時にTrimコマンドが送信されるのみで、運用状態に入るとTrimコマンドの送信は行なわれませんでした。速度低下が不安なユーザーは、SRTの利用解除、再構築を行えばTrimコマンドが送信されますので、定期的にこの操作を行ってみてもよいのではないかと思います。

Trimコマンドの送信條件は、これまできちんとしたコマンドレベルの検証が行なわれなかったこともあり、一部混乱していた部分があったのではないかと思います。今回の検証結果は、コマンドレベルの確認ですので、間違いはありません。

Trimコマンドの対応は、本来機材さえあれば簡単に確認できることは随分前からわかっていたのですが、機材そのものが安価なものでも200万円ぐらいするのでなかなかチェックする機会がありませんでした。チェックできる機会を与えてくれた某社の方に感謝したいと思います。

2012年8月15日水曜日

バスアナでTRIMの動きをみてみました

現在、今月末発売の某PC雑誌の仕事で、プロトコルアナライザ(バスアナライザ、通称バスアナ)をお借りしております。バスアナに触るのは久しぶりだったのですが、やっぱり、楽しいですね。これを使って開発の仕事をするのはマジで辛いと思いますが、雑誌の検証レベルでコマンドをみるだけなら楽しいです。というわけで、今回は、バスアナについて簡単に紹介しようと思います。

今回、お借りしているのは、LeCroy社の「STX M6-1」という製品で、SATA 6G対応の1ポートのプロトコルアナライザ(バスアナ)です。プロトコルアナライザとは、その名の通り、バスに流れるパケットなどをキャプチャして表示する機器です。このため接続は、ホスト(マザー ボードのSATAポート)とSSDなどの機器の中間に配置する必要があります。具体的には、バスアナの入力端子をSATAケーブルで接続し、バスの出力端子とSSDなどのSATA機器を接続します。このようにバスアナをSATAのホストと機器の中間に接続することでバスに流れるパケットなどをごそっとキャプチャする仕組みです。


実際にどのような感じのものがみれるかと言いますと、上の画面のような感じとなります。ストレージ用のデバドラに取り付きコマンドをキャプチャするとソフトウェアのアナライザもありますが、今回のようなハードウェアのバスアナなら、SATA LPMの動きなどもキャプチャできます。この例だと、デバイスからホストに対して、「PMREQ_S」というリクエストが送られています。PMREQ_Sは、スランバーの要求で、PMREQ_Pだとパーシャルです。また、リクエストの方向がデバイスからホストですから、今回のケースでは、DIPMでスランバーのリクエストが送られていることがわかります。ちなみに、HIPMならホストからデバイスに対して同じようにリクエストが送られます。

その下の「PMACK」というのが、ホストからの返信です。この場合、OKなのでPMACKを返しており、SATA LPMの省電力状態に機器が入っています。ちなみにNOの場合は、PMNACKが返ってきます。さらに下にある「COMWAKE」というのが、省電力状態からの復帰要求です。ホストからコマンドが送られてくるので、省電力状態からデバイスを復帰させています。

COMWAKEで機器を復帰させたあとに送られてきたのが、SSDで有名なATAコマンドです。そうこのブログを読んでいらっしゃるかたならご存知の「TRIM」です。TRIMは、正式には「Data Set Management」コマンドと呼ばれます。また、SASにもTRIMと同等のコマンドが準備されており、こちらは、UNMAPコマンドと呼ばれます。

以上のようにバスアナを使うと、ストレージに対してどんなコマンドが送られているかなど、パソコンを使っているだけではわからないような動きを知ることができます。特に今回のようなハードウェアのバスアナなら、信号をまるごとごそっとキャプチャできますので、コマンドの動きなどを把握することができます。

今回なぜこのようなものをお借りしているかというと、実は、TRIMコマンドが送られる条件やRAIDでTRIMが送られるのかなどを調べるためです。バスアナがあれば、コマンドがキャプチャできるので一発です。コマンドがデバイスに送られていれば、TRIMがでている。そうでなければでていません。TRIMの対応非対応の検証は、バスアナでみるのが一番早いのですが、LeCroyさんの一番安いこのバスアナですら200万円ぐらいします。さすがに高価過ぎて、貸し出し申請もし難いという事情もあります。

さて本来なら、ここで検証の結果をお伝えしたいところですが、今回は、さすがに雑誌の発売前なので公表できません。雑誌発売後に時期をみて改めて紹介したいと思います。お急ぎの方は、29日発売のコア向けのPC雑誌をご覧ください。

ちなみにLeCroy社のバスアナは、SATAの公式バスアナとして採用されています。SATA規格は、コマンドシーケンスなどが厳しく定められており、接続されている機器が規定のシーケンスで動作しているかなどをこのバスアナで取得してチェックされます。バスアナは、LeCroyのほか、さまざまなメーカーから発売されていますが、SATAの認証を取るには、LeCroy社のバスアナで取得したログが必要だったと記憶しております。

2012年8月11日土曜日

sandisk SDCZ80シリーズ

前回、最近のUSBメモリは遅いという話を書いたところ、コメントでsandiskのSDCZ80シリーズがすごく速いという話をみて興味が湧きました。調べてみたところ、64GBモデルが6500円ほどで購入でき、高速なUSBメモリの割には安価ということで購入してみました。今回は、sandiskのUSB3.0メモリ、「SDCZ80シリーズ」の64GBモデルのレビューをお届けしたいと思います。速度関係のベンチマーク は、すでにあちらこちらで見かけることができますので、本ブログでは、ちょっとアクセントを付けてSecure Eraseを行ったらどうなるかという点についてもレポートします。


最初にSDCZ80シリーズの諸元について簡単に説明します。本製品は、ネットにでている分解写真をみる限り、NANDメモリのパッケージが1つに、SSD用のコントローラ、SATA-USB3.0変換チップで構成されているようにみえます。つまり、中身は単なるSSDで、それをSATA-USB3.0変換チップでUSBメモリにしているだけのようです。

一部では、中身のSSDがsandiskの「iSSD」という話もでているようですが、これは間違いではないかと思います。というのも、sandiskのサイトみる限り、iSSDは、「μSSD規格」準拠となっています。μSSD規格とは、1つのパッケージ内にNANDメモリとコントローラを積層したワンチップソリューションのSSDです。本製品は、前述したようにSSD用のコントローラがNANDメモリのパッケージ内に積層されていないように見受けられるので、厳密にはiSSDではなく、NANDメモリのパッケージが1つで設計されたSSDとなるのではないかと思います。

ちなみに、μSSD規格で製造できるSSDの最大容量は、現在のところ「128GB」です。これは、NANDメモリのパッケージ加工技術として実用化されているのが「16積層」までだからです。現在のNANDフラッシュメモリのダイ当たり容量は、64Gbit(8GB)ですから「8x16=128GB」が最大というわけです。

本製品の性能ですが、中身がSSDですからさすがに速いです。定番のCrysita Disk Markでは、シーケンシャルリードライトともに200MB/sec前後の速度がでます。512KBや4KBのライトの速度は、イマドキのSSDとしては遅めだと思いますが、USBメモリと比較すれば、段違いの速度です。


次に本製品におけるSecure Eraseの検証結果を報告します。結論から先に言いますと、本製品におけるSecureEraseは、コマンド自体は送られているようです。ただ、その挙動は、一般的なSSDとは異なっています。Secure Eraseを実行すると、本製品に書き込まれていたデータは確かにクリアされますが、速度はSSDのようには復活しません。イメージとしては、単に管理テーブルを「0」で埋めただけのような挙動です。

以下に、検証データを掲載しておきます。一番上が購入後比較的早い段階で取得しておいたHD TUNE Pro 5.0のシーケンシャルライトの結果。2番めが1KB~1MBまでの1000個のファイルの書き込みを1セットとして、1000個書いたら、半分消去を150回ほど繰り返した後の測定結果。一番下が、2番目の検証を行った後、Parted Magicを利用してSecure Eraseを実行後に測定したものです。この結果をみれば、一目瞭然です。一番上のデータがもっとも良く、SecureErase後の結果は、2番目の結果と大差がありません。つまり、データは消去されますが、速度は戻ってきません。


本製品は、USBメモリでありながら中身がSATA-USB3.0変換を用いたSSDということで、Secure Eraseのチェックを行ってみました。Secure Eraseで速度が復活してくれたら、結構画期的だと思ったのですが、なかなか思ったようには行かないようです。

SATA-USB変換を利用してUSB接続にしたSSDでは、Secure Eraseを行えないと思っている方が多いと思いますが、実は、そんなことはありません。確かに中には、Secure EraseのコマンドをフィルタしてしまうようなSATA-USB変換も存在しているようですが、すべてではありません。今回のsandiskのようにきちんとコマンドをスルーしてSSDに送ってくれるような製品も存在しています。今回のSecure Eraseの検証は、実はそれを知っていて敢えて行ってみました。Freeze Lockもかかっておらず、コマンドが通ったところまでは良かったのですが、その後の処理の方法がまさか変更されているとは想像しませんでした。

2012年7月5日木曜日

USBメモリの書き込み速度が遅い(USB3.0対応)

久しぶりの更新になります。
今回は、順調に書き込み速度が低下しているUSBメモリのお話をしたいと思います。

昨今のUSBメモリは、特にUSB3.0対応製品を中心に読み出し速度の高速性のみを紹介し、書き込み速度については触れないとも多くなりました。このため、実際に購入してみたら書き込み速度が異様に遅く、「なぜ?」という方もいらっしゃるようです。そこで今回は、USBメモリやSSDの速度がどこで決まるかという話を中心に、昨今の事情を解説したいと思います。

本Blogをよく読まされている方なら常識かもしれませんが、SSDやUSBメモリの理論上の最大速度は、NANDフラッシュメモリの「インターフェース速度 x コントローラの物理チャンネルの数」によって決まります。SSDの場合ですと、コントローラに搭載されたNANDフラッシュメモリ接続用の物理チャンネルは通常「8個」。USBメモリの場合は、1、2、4個の3種類のコントローラがあるようです。

インターフェースの速度は、大きく2つあります。1つが、同期モードです。ONFI NV-DDR 1.0の場合で166または200MB/sec。東芝とSAMSUNGが推進しているToggle DDR 1.0の場合で133MB/secです。次世代のONFI NV-DDR 2.0及びToggle DDR 2.0なら400MB/secとさらに高速化されます。もう1つがAsyncモード(非同期転送モード)です。Asyncモード時の速度は、公開されていないので詳細は不明ですが、NV-DDR 1.0やToggle DDR 1.0の半分前後ぐらいだと思っていればよいかと思います。

上記を前提としますと、SSDは通常、物理チャンネルが8つありますので、同期モードの場合、最大1600MB/sec。USBメモリは、同期モードの場合で、1チャンネル品が200MB/sec。2チャンネルなら400MB/sec。4チャンネルなら800MB/secが最大速度ということになります。つまり、USBメモリの場合、最大速度が100MB/sec程度でよいなら、1チャンネル品のコントローラで十分事足りるということになります。

次に書き込み速度についてですが、これを決める要素は、「NANDフラッシュメモリ単体の書き込み速度 x 並列アクセスバンク数(同時にアクセスできるダイの数)」です。つまり、素のNANDフラッシュメモリの書き込み速度が10MB/secだと仮定すると、1ch接続でもダイが2個あれば、2Wayインターリーブを使って20MB/sec、4個あれば4Wayインターリーブで40MB/secの速度がでます。最近のUSBメモリの書き込み速度が何故遅いかという原因は、まさにここにあります。要するにUSBメモリに搭載されているNANDフラッシュメモリのダイの数が少ないのです。

加えて、最近のUSBメモリは、SSDで一般的なMLCタイプだけではなく、TLCタイプも使用されているようです。これが、USBメモリの書き込み速度の低下に拍車をかけています。

TLCタイプのNANDフラッシュメモリは、読み出し速度こそMLCタイプとほぼ同じですが、書き込み速度は、MLCタイプの半分ぐらいしかありません。しかもTLCは、ダイ当たりの容量が64Gbit(8GB)のものが一般的です。一方、MLCの場合は、32Gbit品と64Gbit品の両方が現在の主流です。

まとめますと、現在のUSBメモリの書き込み速度の低下には、大きく2つの要素があります。1つが、NANDフラッシュメモリ自体の書き込み速度の低下です。これは、製造プロセスの微細化による速度低下とMLCではなく、TLCを使うことによる速度低下です。2つ目が、NANDフラッシュメモリの大容量化です。現在のNANDフラッシュメモリは、MLCの場合で32Gbitと64Gbit品の2種類があり、TLCの場合は、現時点で64Gbit品が主流です。このため、8GBモデルなら1つのダイで製造でき、16GBモデルでも2つのダイで製造できてしまいます。同時にアクセスできるダイの数そのものが少ないのですから、書き込み速度があがるわけがありません。

特に現在の安価なUSBメモリは、TLCタイプが採用されている可能性が高いので、購入時には、最初から速度は割り切っておいた方が良いと思います。実例をお見せします。以下のベンチマーク結果は、先日「400円」で購入したLexar MediaのJUMPDRIVEという8GBのUSBメモリ(USB2.0接続)の速度です。リードこそ20MB/secほどでていますが、ライトは、7MB/secほどしかでていません。TLCタイプのNANDフラッシュメモリの書き込み速度は、7MB/sec前後ぐらいだったと思いますのでその速度に合致しています。MLCの64Gbit版のダイ1つの可能性も否定はしませんが、MLCの場合、だいたい10MB/secぐらいの速度がでます。価格も考慮して考えると、本製品に採用されているのは、非同期モード専用品のTLCタイプのNANDフラッシュメモリの可能性が高いと思われます。


もう一つ、LexarのJUMPDRIVEと一緒に「800円」で購入したSUPER TALENTのUSB3.0 Express ST1の16GBモデルのベンチマークも載せておきます。この製品もJUMPDRIVEに負けず劣らずでなかなか素晴らしい結果です。リードこそ90MB/secほどでていますが、ライトはなんと12MB/sec弱。どうみてもNANDフラッシュメモリがTLCタイプっぽい速度です。推測ですが、おそらくこの製品の搭載メモリは、TLCタイプで同期モードなのだと思います。16GBモデルなので、64Gbit(8GB)のダイが2つで1ch接続の2Wayインターリーブまたは2ch接続なのでしょう。


最近のUSBメモリは、低価格化のためにTLCタイプのNANDフラッシュメモリを採用する例が増加しているようです。これによって、特に安価なモデルを中心により一層書き込み速度が遅くなっています。上記のSUPER TALENTの例を考えると、USB3.0対応の32GBモデルですら書き込み速度が25MB/sec前後の製品が以外に多いのかもしれません。昨年までのUSB3.0接続のUSBメモリは、同期モードのMLCタイプを採用しているというイメージでしたが、現在は、同期モードのTLCタイプに変更されてきているという感じがします。少しでも高速な製品が欲しいときは、入念な下調べが必要なのだと思います。

2012年4月29日日曜日

イマドキのSSDの消費電力(2012年4月版)

ネットを見ていると最近は、SSDの消費電力を気にする方も多いようです。
たまたま、ワットチェッカーが手元にあったので、イマドキのSSDの消費電力を測定してみました。今回は、その結果をレポートしてみたいと思います。

今回チェックしたSSDは、「Plextor PX-128M3P」「Plextor PX-256M3P」「Crcial m4(128GB版)」「Intel SSD 520(120GB版)」「SAMSUNG 830(128GB版)」「東芝 THNSNS120GBSP」の6製品です。同じコントローラでNANDメモリのメーカー違いや容量違いなどをセレクトしたので、現在のSSDの消費電力のだいたいの傾向がつかめるのではないでしょうか。

測定環境は、マザーにASRock社のZ68 Extream4 Gen3を利用し、BIOS設定でC1E、C6 State、SATA Aggressive Link Power Managementの各設定を「Disable」にしています。OSは、Windows 7 Ultimate SP1 64bit版を利用しました。また、Windowsの電源オプションのハードディスクの「次の時間が経過したらハードディスクの電源を切る」の設定は「オフ」、スリープ関係の設定はすべて「オフ」、PCI Expressの「リンク状態の電源管理」も「オフ」です。さらに、SATA LPMの設定は、既定値(オン)のままにしてあります。

余談ですが、上記の設定が、僕が雑誌等でSSDのベンチマークを行うときの設定です。利用しているSSDが、雑誌の結果と大きくかけ離れている場合は、上記の設定を行ってベンチマークを行ってみてください。これでだいたい同じ速度がでるようになるはずです。

また、最大消費電力(Max)は、IOMeterで16KBのランダムライトと1MBのシーケンシャルライトをそれぞれ3分間ずつ行い測定しています。ライトで消費電力を測定しているのは、いろいろ試してみたところリードよりもライトの方が、消費電力が高かったからです。最小消費電力(Min)は、テスト終了後、20分ほど放置してその間の最小値を測定しています。結果は、下のグラフをみてください。


消費電力がもっとも高かったのが、SAMSUNG 830の「5.3W」でした。この数字は、ダントツです。やはり、トリプルコアのコントローラが電力を食っているのでしょうか、イマドキのSSDとしては、かなり高い消費電力といえます。次点は、THNSNS120GBSPの「4.4W」です。THNSNS120GBSPは、連続した書き込みが続くとかなり発熱しますが、消費電力は、発熱の多さほどではないようです。薄いアルミの筐体に熱を流している分、他の製品よりも熱く感じてしまうのではないでしょうか。また、最大消費電力がもっとも低かったのは、PX-128M3Pでした。この製品は、性能の割に消費電力が低い製品といえます。

注目したいのは、PX-128M3PとPX-256M3Pの結果です。書き込み速度が上がれば、それだけ消費電力が高くなることは誰でも想像できますが、想像通り、PX-256M3Pの方がPX-128M3Pよりも「0.6W」ほど消費電力が高くなっています。NANDメモリが異なるので、単純な比較はできませんが、これから推測すると、SAMSUNG 830の256GB版は、6W近い最大消費電力になりそうです。

また、最小消費電力は、Toggle DDRの東芝/SAMSUNGグループとONFiのIMFTで綺麗に別れています。Toggle DDR採用のPX-128M3P/PX-256M3P、THNSNS120GBSP、SAMSUNG 830は、いずれも「0.6W」。ONFiのCrucial m4、Intel SSD 520は、それぞれ1Wと1.1Wでした。消費電力と性能を考えた場合、今回チェックした製品の中でもっともバランスが良かったのは、Plextorの製品ということになると思います。

最後に東芝のTHNSNS120GBSPの発熱についてふれたいと思います。消費電力のテスト前とテスト後の温度をCrystal Disk Infoで比較してみました。結果は、以下のようになりました。


上の画面がテスト前の温度、下の画面がテスト後の温度です。センサーが正しいなら、わずか6分間の連続書き込みで温度が50度まで上昇していることになります。これはかなり高い温度だと思います。通常の利用では、OSインストールやバックアップの復元などを除き、最大速度で5分を超えて連続して書き込みを行うような機会はそれほど多くはないと思います。このため、ここまで温度が上がるケースは、それほど多くはないと思いますが、ノートパソコンで使いたい方は頭の片隅にいれておいた方がよいでしょう。

2012年4月24日火曜日

TOSHIBA THNSNS120GBSPの速度低下について

前回の記事をアップしたあとに東芝の最新SSD「THNSNS120GBSP」をある程度使ったら、シーケンシャルライトの速度が低下したままになるというコメントを頂きました。
このコメントが非常に気になったので、僕の方でもこの現象について検証してみました。今回は、その結果をレポートしたいと思います。

検証は、IOMeterを使って行いました。ライトパターンは、1MBのシーケンシャルライト15秒間です。これをワンセットとして計40回、10分間の書き込みを行いました。その結果が、以下のグラフです。グラフの青の線が書き込み速度、赤の線が総書き込み容量です。


この結果をみてもらうとわかりますが、本製品の場合、公称記録容量(ユーザーデータエリア、本製品の場合111.79GiB)を超える120GiB(グラフではGB表記していますが、GiBです)のデータを書き込むとシーケンシャルライトの速度が約240MB/secに低下し、以降はこの速度のまましばらく推移します。Marvell製コントローラ採用製品では、これと同じテストを行っても、シーケンシャルライト速度が低下することはありません。しかし、Sandforce製コントローラの場合は、必ず、速度が低下するようです。これは、Intel SSD 520の結果から推測できます。


上記のグラフは、Intel SSD 520でTHNSNS120GBSPと同じテストを20分間行ったときのグラフです(計測時間が長くなっているのは、書き込み速度が異なるからです)。速度低下の大きさや速度低下するまでの総データ書き込み量はTHNSNS120GBSPとは異なりますが、Intel SSD 520も同じように速度が低下し、よく似た傾向のグラフとなっています。Sandforce製コントローラを採用したSSDの場合、初期速度と記録容量一周分のデータを書き込んだあとでは、明らかに書き込み速度が異なります。Sandforce製コントローラでは公称記録容量付近まで連続してデータを書き込むと、書き込み速度が低下する仕様なのだと思います。いうまでもありませんが、この状態から初期速度に戻すには、SecureEraseを行うのがもっとも手っ取り早い方法です。

なお、速度低下が始まる総書き込み容量が、THNSNS120GBSPとIntel SSD 520とで異なっています。これは、THNSNS120GBSPの方が、 より積極的に実際に記録可能なエリア(NANDメモリの総容量)を利用する仕様になっているからだと推測されます。

THNSNS120GBSPは、こんな盲点があるとは気づきませんでした。前回記事でコメントを頂いた方に感謝したいと思います。

2012年4月16日月曜日

TOSHIBA THNSNS120GBSP

前作HG3から実に1年以上も経過してしまいましたが、東芝ブランドの最新SSDが発売になりました。早速、120GB版の「THNSNS120GBSP」を購入してきたので簡単に紹介したいと思います。

まず、本製品に採用されているコントローラ「TC58NC5HJ8GSB-01」は、ネットでも話題になっているように自社製コントローラではありません。Sandforce社のSF-2281/2282をベースとしたカスタムコントローラが採用されています。なにをどのようにカスタムしたかの詳細は不明ですが、普通に考えるとメインの機能などはそのままで、NANDメモリの取り扱い部分が変更されている可能性が高いと思います。つまり、東芝製Toggle DDR NANDメモリに最適化したと考えるのが自然でしょう。

余談ですが、本製品は、HG3の事実上の後継製品となるようで2.5インチ版だけでなく、mSATA版なども展開されるようです。このため、近い将来、本製品のmSATA版を搭載したノートPCなども登場すると思われます。

次に各種ベンチマーク結果を紹介します。今回は、ベースコントローラが同じIntel SSD 520とOCZ Technology Vertex3との比較で紹介します。THNSNS120GBSPとIntel SSD 520/Vertex3の違いは、NANDメモリとファームウェアです。THNSNS120GBSPは、いうまでもなく東芝製Toggle DDR NANDメモリを採用(24nmプロセス製造品)し、東芝の手が入ったカスタムファームを採用しています。Intel SSD 520/Vertex3は、いずれもIMFTの製造した25nmプロセスのNANDメモリをONFiの同期モードで使用しています。ファームウェアもIntel SSD 520は、Intelの手が入ったカスタムで、Vertex3が、もっとも独自部分が少ないファームウェアと推測されます。

定番のCrystal Disk Marの結果は、以下の通りです。 THNSNS120GBSPは、これまでのSF-2281搭載した製品は何だったのというぐらいシーケンシャルライト速度が強烈に速く、120GBモデルですら390MB/sec強の速度がでます。この速度は、Intel SSD 520やVertex3との比較で約2倍も速く、350MB/sec前後のPlextor M3PシリーズやSAMSUNG 830よりもシーケンシャルライト速度は高速です。また、Sandforce製コントローラらしく、圧縮が効く0Fillでは、さらに速度が速くなります。ただし、Intel SSD 520と同様でシーケンシャルリードに関しては、若干、Vertex3の方が速いようです。

実環境をエミュレートするPC Mark Vantage HDD Test Suiteの結果もSandforce製コントローラでは、最高の83000オーバーのスコアを実現。このスコアは、Marvell製コントローラを搭載したPlexter M3Pシリーズと同等です。


最後にIOMeterを利用し、4KBランダムライトを30秒間ワンセットで60分間行った場合の速度推移や平均レスポンスタイム、最大レスポンスタイムの推移をグラフ化したものを掲載しておきます。この結果ですが、ベースが同じコントローラとは思えないほどの違いがでました。

特に着目して欲しいのが、平均レスポンスタイムの推移です。Intel SSD 520/Vertex3は、同じNANDメモリを採用しているためか、多少の違いはあるものの同じような傾向を示しています。しかし、THNSNS120GBSPは、それとは全く異なり、常に地をはうようなレスポンスタイムの低さで推移し、途中からレスポンスタイムが大きく増加するというような傾向もでていません。このレスポンスタイムの低さは、現役屈指かもしれません。


また、最大レスポンスタイムも最大値こそIntel SSD 520/Vertex3を大きく超える140ms弱を記録していますが、それを除けば、全体的にIntel SSD 520/Vertex3よりも低く抑えられています。Sandforce製コントローラは、比較的最大レスポンスタイムも低めなのですが、この全体的な低さも現状のトップクラスといえます。


速度推移グラフも、Intel SSD 520/Vertex3が常に安定しているのに対し、THNSNS120GBSPは、速度が低下するまで上下を繰り返すなど多少傾向が異なります。また、東芝製Toggle DDRの方が基本的に高速なのかはわかりませんが、速度低下後も常にIntel SSD 520/Vertex3よりも速めの速度で推移しています。


以上のことからもわかるように、THNSNS120GBSPは、こと速度面に関しては、現在発売中のSandoforce製コントローラ採用SSDの中でもっとも高速な製品です。この差が、NANDメモリの性能差なのか、ファームウェアの差によるものか、その両方なのかはわかりませんが、うまくチューニングされているとことは間違いありません。あとは、致命的なバグなければ良いのですが。そこは、東芝様です。開発体制が大きい(僕の知る限り、SSDの開発体制の大きさではトップクラス。現在大人気の某社の3倍から4倍の人がいます)ので、致命的なバグは潰していることに期待したいと思います。

なお、現在人気のPlextor M3PシリーズとTHNSNS120GBSPの比較ですが、個人的には初期性能はほぼ同レベルだと思っています。あとは、ネットでも言われている速度の落ちにくさですが、Plextor M3Pシリーズは、かなり頻繁にGCを行うことで速度低下を防いでいるようなので、そのあたりでどのぐらい差がでるかだと思います。唯一難点を挙げるとすると、THNSNS120GBSPは発熱が大きいことです。これは、東芝の筐体が薄めのアルミということも関係していると思いますが、ちょっと連続で書き込みを行うとそれなりに発熱します。温度的には、SAMSUNG 830ぐらいは出ていると思います。ノートパソコンでの使用を考えている方は、そのあたりも気を付けた方がよいかもしれません。

2012.4.24追記
THNSNS120GBSPの書き込み速度の低下についての記事を追加しました。

2012年3月3日土曜日

PX-M3Pの同等品?Liteon S100シリーズ「LAT-128M3S-16」

PlextorのM3Pシリーズの同等品と思われるLiteonのS100シリーズの発売が始まりました。この製品の128GB版を購入したので、今回は、先日購入したPlextor PX-128M3Pとの比較で簡単にレポートしたいと思います。

本製品は、多くの方がご存知のとおり、PX-128M3Pと同じ「PLDS(PHILIPS & LITE-ON DIGITAL SOLUTIONS)」が開発製造した製品です。光学ドライブの場合、PLDSの製品は、LITEONブランドで販売されることが一般的でしたが、SSDの場合は、製造元のPLDSがPlextorブランドで販売するだけでなく、親会社のLITEONからも販売されることになったようです。

本製品は、ネットでは、すでに姉妹品?とか同等品とか言われていますが、分解してみたところ、外部キャッシュは、同じNANYAのチップを使っており、容量は256MBでした。また、コントローラのリビジョンがちょっとアップしていますが、その他の部品構成は、ほぼ同等でした(コントローラが実装されている面にPX-128M3Pはチップが1つ実装されていますが、LAT-128M3S-16には実装されていません)。基盤リビジョンもPX-128M3Pと全く同じです。このことからも、ほぼ同じハードウェアと考えてもらって差し支えないとい思います。筐体も色と厚みが異なるぐらい(PX-128M3Pは「7mm」、LAT-128M3S-16は「9.5mm」)です。


なお、コントローラについてですが、 PX-128M2Pは、Marvellの88SS9174‐BKK2でしたが、PX-128M3P/LAT-128M3S-16は、Crucial m4と同じ「88SS9174‐BLD2」となっています。C300が、88SS9174‐BJP2だったので、BJP、BKK、BLDと末尾が変わってきています。次は、BMxとなるのかもしれません。

次にベンチマーク結果を紹介します。定番のCrystal Disk Markの結果は、リードに関しては完全に同等という感じです。ライトに関しても、シーケンシャルや512KBに関しては同等です。ただ、4KB(QD=1)に関しては、LAT-128M3S-16の方が少し悪いようです。また、PC Mark Vantage HDD Test Suiteの結果もほぼ同じです。



IOMeterで4KBランダムライトを60分間行ったときの速度推移やレスポンスタイム、最大レスポンスタイムの推移もグラフ化したので掲載しておきます。これらをみてもわかりますが、速度推移やレスポンスタイムの動きは、ほぼ同等という感じです。ただ、最大レスポンスタイムは、大きく異なっています。PX-128M3Pは、上下が少なく安定していますが、LAT-128M3S-16は、かなり数値が上下しているだけでなく、高いレイテンシが測定されてしまいました。

以上のことからもわかるように、LAT-128M3S-16は、基本同じ製品と考えてもらって差し支えないと思います。ただ、ファームウェアも現状のPX-128M3Pと同じかと言われると、最大レスポンスタイムが比較にならないほど高いという違いがあるため、微妙に違う気がします。

PX-128M3Pは、3,5インチマウンタと5年保証に加え、AcronisのOEM版が付属します。対して、LAT-128M3S-16は、3.5インチマウンタは付属しますが、3年保証で、ソフトは付属しません。価格差は、現状では、2000円ぐらいLAT-128M3S-16の方が安いといったところです。これに性能面の若干の差(長いレイテンシがでる)という点を加えて、購入したい方は判断されるとよいと思います。

LITEONは、光学ドライブでもそれなりにファームウェアのバージョンアップを行なっていたので、ファームウェアの積極的なバージョンアップに期待したいと思います。

2012年3月1日木曜日

Intel SSD 520シリーズを検証

Sandforce社のSF-2281をコントトーラに採用したSSDは、さまざまなメーカーから発売されていますが、Intel社からもSF-2281を採用したIntel SSD 520シリーズの発売が始まりました。PX-128M3Pと一緒にIntel SSD 520の120GB版も購入したので、今回は、この製品のレポートを同じコントローラ、同じNANDメモリを搭載したVertex3との比較で行いたいと思います。

まずは、定番のCrystal Disk Markの結果です。
結果は、リードで若干、SSD 520の方が遅めですが、ライトでは、逆の結果となっています。誤差かなという気もしないわけではありませんが、この差は、後述する4KBのランダムライトの推移グラフをみると明らかな違いとなるので、差があることに間違いはありません。


次にIOMeterの4KBランダムライト(QD32)を60分間行ったときの速度推移グラフ及びレスポンスタイムと最大レスポンスタイムの推移グラフを作成したので、それをみてください。速度推移では、SSD 520の方が、Vertex3の速度を若干ですが常に上回っていることがわかります。また、レスポンスタイムの推移でも同様で、SSD 520の方が、常にレスポンスタイムが短く、最終的には、約「1ms」もの差がでてしまいました。一方で、最大レスポンスタイムの推移では、初期時にSSD 520の方がちょっと高めですが、途中からほぼ同じレベルで推移しています。


これらの結果からもわかるように、SSD 520とVertex3は、全体的な挙動は共通ですが、性能差があることがわかります。その差は、明白でSSD 520の方ができがよいことは間違い有りません。同じコントローラ、同じNANDメモリを使っての差ですから、おそらく、このあたりが、Intelが独自行った性能部分におけるチューニングなのではないでしょうか。

同じようなテストをIntel製25nmプロセス製造のNANDメモリ、SF-2281搭載のA-DATA S511でも行ったことがあります。そのときのA-DATA S511の挙動と性能は、Vertex3のそれとほぼ同じでした。つまり、Vertex3とS511は、ほぼ同じ挙動を示す同じ性能の製品です。しかし、SSD 520は、それを上回っています。SSD 520は、Sandforce製コントローラ「SF-2281」を採用したSSDの中で、現時点では、最高の性能を実現した製品だと思います。(現時点では、と書いたのは、他にもSF-2281を採用した大手のものがあるからです。その製品もそのうちでてくると思います)

最後にSandforceのSF-2281もIntel(ともう一社)の手が入って、ファームウェアがかなり良くなった感じがあります。このファームが完成したのが、恐らく、年末ぐらいだと思います。これらが反映されたファームウェアが、A-DATAさんやOCZさんなどからもリリースされると、ユーザー的には嬉しいのではないかと思います。A-DATAさんやOCZさんが、次にリリースするファームウェアでこの成果を反映していることを期待したいと思います。

2012年2月28日火曜日

Plextor PX-128M3P

なかなかBlogの更新まで手が回らなくて申し訳ありません。
Plextorブランドの新製品「PX-128M3P」を購入したので、今回は、この製品のレポートを簡単にしたいと思います。

まず、この製品ですが、前作PX-128M3と物理的に何が異なっているのかよくわかりません。噂では、ファームウェアが異なるのみという話もありますが、実際のところどうなのでしょう?世の中には、A-DATAのS510とS511のようにNANDメモリの動作モード(非同期モードと同期モード)の違いで廉価版とそうでない商品を作り分けている場合もあります。コストが同じなのに敢えて作り分けているのには、何か理由があるのでしょうが・・・。

話がちょっとそれてしまいましたが、今回は、人気のCrucial m4との比較でPX-128M3Pの性能をチェックしてみたいと思います。PX-128M2PやPX-128M3との比較でチェックしろという方もいるかもしれませんが、両方ともに個人的に購入していません。このため、某雑誌でテストしたときの結果等を踏まえてコメントしていきます。PX-128M2P/M3の実際の数値に関しては、雑誌等で確認していただけたらと思います。

まず、定番のCrytal Disk Markです。結果は、以下の画面をみてもらえば、わかります。リードに関しては、ほぼ同等。ライトは、PX-128M3Pの方が高速といった感じです。ちなみに、PX-128M3は、シーケンシャルリードが200MB/.sec強にとどまり、4KBに関しては、リードライトともにPX-128M3Pとほぼ同等です。ただし、4KB QD32のときの速度は、PX-128M3Pの方が100MB/secほど速くなります。つまり、PX-128M3とCrucial m4はほぼ同等の速度で、PX-128M3Pは、それらよりもシーケンシャル速度が速い製品という感じです。


次に、PC Mark Vantage HDD Test Suiteの結果です。このテストでは、PX-128M3Pの方が、約2000ほどスコアが上です。僕の手元にある某雑誌のテスト結果では、PX-128M2P/M3でも、PX-128M3Pとほぼ同じぐらいのスコアとなっています。というわけで、このテストの結果は、Crucial m4よりも高いですが、PX-128M2P/M3からは、大きく変化していないということになります。


最後にIOMeterを使って、Secure Eraseを行った後に60分間4KBのランダムライト(QD32)を行った場合の書き込み速度の推移グラフとResponse Timeの推移グラフ及びMax Response Timeの推移グラフを作成したのでそれを掲載しておきます。

まず、速度推移のグラフですが、みての通り、ある地点で極端に書き込み速度が低下し、速度低下後は、ほぼ同じぐらいの書き込み速度のまま推移しています。このテストのように長い時間ランダムライトが継続すると、最終的に両者はほぼ同じ速度になるようです。加えて、PX-128M3PもCrucial m4と同じで、積極的に未記録エリアに書き込みを行う仕様となっていることがわかります。リビジョンが多少異なりますが、基本同じ設計のコントローラを両者ともに採用しています。未記録エリアを積極的に使う仕様は、コントローラの特徴なのかもしれません。

なお、速度低下した部分が、記録容量いっぱいに達した部分です。PX-128M3Pでは、約8分30秒ぐらいの地点、Crucial m4では、12分30秒ぐらいの地点がそうです。PX-128M3Pは、初期速度が270MB/sec。Crucial m4は、初期速度180MB/secと速度差があるため、速度低下が発生する地点が異なっています。


興味深いのは、Response Timeの推移グラフ及びMax Response Timeの推移グラフの比較でしょう。両者を比較するとわかりますが、平均的なResponse Timeでは、Crucial m4の方がわずかですが、低めとなっています。しかし、Max Response Timeは、逆の結果となります。Crucial m4の方が長めのResponse Timeが発生しており、最大値は、1700ms(1.7秒)とかなり長いResponse Timeが計測されてしまいました。これを見るかぎり、連続した書き込みが続く環境下では、Crucial m4は、PX-128M3Pよりも長いレイテンシが発生するようです。


Max Response Timeは、同じコントローラでもかなりの差がでていますが、これが、ファームウェアによるものなのかNANDメモリに違いによってでているものなのかは不明です。いずれにしても差があることは事実です。僕は、あまり大きなレイテンシは、よろしくないと思っているので、PX-128M3Pの方がよいと思っています。