JMF601/602シリーズに関してのJMicronへのインタビュー

DailyTechの記事に、JMicron社に対するインタビューが掲載されていました。興味深い記事なので、その内容について紹介したいと思います。

まず、JMF601/602のバージョンについて。
JMF601/602シリーズには、JMF601A/602Aと、JMF601B/602Bという2つのバージョンがあります。JMF602Aを搭載している製品はOCZ Core V1, SuperTalent MasterDrive MXなどの旧シリーズで、最大読み込み速度が120MB/s程度、最大書き込み速度が80MB/s程度です。現在販売されている最大読み込み速度150〜170MB/s、最大書き込み速度90〜100MB/sのSATA製品は、JMF602Bを搭載しています。また、EeePC901-16G, S101などの16GBのSSDは、JMF601Bを搭載しています。
JMF602搭載SSDプチフリ問題を初めて数値的に明らかにしたのは、このAnandTechの記事です。Iometerを用いた計測により、ランダムライトパフォーマンスが異常に悪くなる現象が報告されています。
AnandTechの記事はCore V1(JMF602A搭載)を用いていますが、JMicron社はこの問題はJMF602Bで改善されたと主張しています。実際に、Core V2を用いたこだわりのMONOさんの記事では、AnandTechの計測値より多少良い結果になっています。
しかし、DOS/V Power Reportの2009年2月号の記事にあるように、JMF602のパフォーマンスは未だに他のSSDに比べて非常に悪いです。上記のDailyTechの記事では問題が解決されたかのように書かれていますが、まだ改善の余地は大いにあります。


次に、インタビューの中で興味深い箇所を何箇所かピックアップし、解説を加えてみました。

  • 書き込みの遅延が大きい問題は、特殊な状況で起こる。すなわち、システムデータが一杯に近く、それでもホストPCがデータの書き込みを続けた時である。ガベージコレクション、データのマージ、ハウスキーピング処理に時間がかかっている。

予想されていたことではありますが、JMicron社がはっきりとこの件に言及したのは初めてではないでしょうか。
ガベージコレクションとは何かということについては、Blackfin空挺団さんの記事が大変分かりやすくて参考になります。マージとは集めた有効な部分のデータを結合すること、ハウスキーピング処理とは不必要な部分を捨て、整合性を保つ作業です。
JMF602Bを搭載したMLC-SSDの場合、多くはブロックサイズが512KBx8=4MBもあるのにも関わらず、JMF602Bのバッファは64KBしかありません*1。すなわち、ブロック全体をコピーするには、4096/64=64回のコピー処理が必要となる計算になります。そのため、ガベージコレクションの処理が重くなってしまうのでしょう。
一方、ブロックサイズが1MBしかないSLCの8GBのモデルでは、ガベージコレクションにかかる時間は少なくなることが予想されます。実際に、SLCの8GBでのテストを行った当ブログ内の記事では最大書き込み遅延は160ms程度なのに対し、MLCタイプを用いた前述のこだわりのMONOさんの記事では約700msの遅延が、DOS/V Power Reportの2009年2月号の記事ではほとんどの機種に900ms程度の遅延が発生しています。チップセットベンチマークの内容の差があるため厳密には比較できませんが、MLC製品は概ねSLC製品の4倍以上の遅延があり(4倍よりMLCが遅いのは、SLCとMLCの性能差そのものによると思われます)、前述のブロックサイズの問題と辻褄が合います*2。なお、SLCの32GB以上のモデルはブロックサイズが2MBあるようなので、8,16GBより最大遅延はむしろ悪くなってしまう可能性があります。
「システムデータが一杯に近いとき」(原文: when the system data is close to full)というのが具体的にどういう状況なのかはよく分からないです。おそらく、HDTuneの書き込みテストで、最初しばらくは早いのに途中からグラフがガタガタになっている状態がこれに相当するのではないでしょうか。

  • プチフリ問題を軽減するために、予備ブロック数を増やすことができる。しかし、見た目の容量が減少するため、SSDのメーカは予備ブロック数を増やさない傾向にある。

OCZのCore V2シリーズなどは、他のメーカより若干OSから見える容量が少なめです*3。これは、予備ブロック数を他の製品より多く取っているためです。なお、この予備ブロック数は、JSMonitorで"System Block Count"という名称で取得できます。
Core V1でプチフリが大きな問題となったため、OCZは見た目の容量を減らしてでも性能を向上させようとしたのでしょう。この決断は、そういった事情が分かっていない人が書いた記事では、OCZ製品は容量が少ないから損です、といった結論が出されがちなので、商業的にはマイナスだったかもしれません。

JSMonitorではファームウェアの名称を取得することができます。おそらく、 "02.10102","02.10103","02.10104"という名前のファームウェアJMicron社製で、トランセンドや恵安の日付の入った名前のファームウェアが各社独自のものと思われます。ファームウェアの差が具体的にどのように変化をもたらすかは断片的にしか分からないのですが、DailyTechでは今後その点についての記事を掲載する予定があるようなので、期待して待ちましょう。

  • JMicronは、プチフリ問題を完全に解決するために、DRAMキャッシュを搭載する新コントローラを開発中である。

噂には上っているJMF611/612シリーズでしょう。大きなDRAMキャッシュがあればブロックコピーが一発で行えるので、少なくとも数百msという時間はかからなくなるはずです。また、ある程度の書き込みがあるまでデータを溜め込んでおけるため、設計しだいで実際のNANDへの書き込みの機会を減らすこともできると思います。
まあIndilinxに先を越されてしまったわけですが…

  • JMF601/602はネットブックやノートPC用にデザインされている。それらのコントローラは、サーバーやヘビーな処理(例えば複数のタスクによる同時アクセス)にはあまり適していない。

認めちゃった…orz
数少ないとはいえ、SLC製品の立場はどこに行ってしまったんでしょう…

*1:MemoryCorp社のデータシートより

*2:この部分の考察は、2009年1月24日に加筆しました

*3:PC Watchの記事を見てそう書いたのですが、実際には他の製品と同じかもしれません。現在確認中です

*4:JMicron社の人が語った内容ではなく、インタビュアーのNote上での記述