2009-09-11
■[SSD]P55 Deluxe付属"SATA3 Card"と新SSD(?)SD88SA02の情報

OCWorkbenchのこの記事に、ASRock製のマザーボードP55 Deluxeに付属する”SATA3 Card”と、謎の新SSD"SD88SA02"のベンチマークが掲載されているので、ちょっと紹介してみます。
ご存じの通り、最近のSSDのシーケンシャルアクセス速度の向上はめざましく、SATA 2.0(最大300MB/s)の規格がボトルネックになりつつあります。そのため、最大転送速度が600MB/sとなるSATA 3.0の普及が期待されています。
最近発売されたP55マザーボードの一部は、当初はSATA 3.0に対応する予定があったようですが、実際には見送られてしまいました。しかし、「変態」マザーで有名なASRockは、同社製のハイエンドP55マザーボード「P55 Deluxe」にPCI Express x1接続のSATA3.0カードを同梱し、無理矢理(?)SATA 3.0に対応させています。現在のところSATA 3.0に対応したストレージは市販されていないため、一般ユーザがこれを手に入れてもあまり意味はないのですが、OCWorkbenchではいち早く"SD88SA02"という名称の(おそらく開発中の)SATA 3.0対応SSDを用いたテストが行われています。
記事によると、"SATA3 Card"はMarvell社の"Marvell 9123"というチップを使用しており、"SD88SA02"にもMarvellのコントローラチップが使われているとのことです。MarvellがSSDのコントローラを作っているというのは初耳ですね。
ベンチマーク結果は、HD Tachを用いた全領域へのシーケンシャルリードの平均値は305.6MB/s、Iometerの"Total MBs per Second"が394.57MB/sとなっており、SATA 2.0の転送速度の最大値を上回っています。Iometerのテスト内容は本文中には明記されていませんが、画像の数値から計算する限り、Transfer Size=250KB,Queue Depth=32でのテストのようです。アクセスパターンも謎ですが、おそらくHD Tachでシーケンシャルリードの測定を行っていることから、Iometerの方もシーケンシャルリードの結果なのではないでしょうか。ライトに関するテストは行われていませんが、MLCタイプのSSDであればシーケンシャルライトの速度はシーケンシャルリードの半分から3分の2程度となるため、SATA 2.0でもボトルネックにならないくらいの速度になると思われます。
個人的には、というか多くのSSDユーザーにとって、もはやシーケンシャルでのアクセス速度がこれ以上早くなってもそれほど嬉しくない気がします。むしろこの新型SSDのランダムアクセス速度はどの程度なのかが気になります。というわけで、続報に期待しましょう。

僕の予想ですが、この石は、結構性能が良いのではないかと思います。
なんせ、Intelの石は、Marvellとの共同開発品というかMarvell開発?と
いう話があるぐらいですから。(真偽のほどは知りませんが)
最終的にはファームのできなどにもよりますが、速度面で期待ができる
石であることに間違いはないかと思います。
また、速度面からみると16ch並列ではないかと思います。
20ch並列の可能性もありますが、ノートPCで使える消費電力のことを考
えると16ch並列の可能性が高いと予想します。
いずれにしても新しい石がでてくることは良いことです。
東芝さんやSAMSUNGも年末には新しい製品が発表されるでしょうから楽し
みですね。
そういう点でメーカーを問わず新型コントローラに期待しますが
なかなか出てこないので完全に待ちぼうけ状態ですね
JMF612はどうなったやら・・・
http://akiba-pc.watch.impress.co.jp/hotline/20090912/etc_intelevssd.html
X-25シリーズはキャッシュがえらく小さいとか、内容的には
なんか微妙な感じです
S.M.A.R.T情報も秋には公開とか
Lansenさん公開されたら是非JSMonitorに反映させて下さいね
それまで30nmモデルは買うのペンディングにしときます...
ということはMarvellには結構期待できるかも?意外な伏兵ですね。
新型と言えば、TDさんのおっしゃるJMF612もMTRONの新型もSanDiskのも最近音沙汰ないですが、一体どうなってるんでしょうね…
>piyopiyoさん
別口で大きな画像を見つけたのですが、Intel SSDの不明なアトリビュートの内容は以下の通りのようです。
E1 LBA's Written
E8 Available Reserved Space
E9 Media Wearout Indicator
B8 End-to-End Data Integrity Error Count
やはりE8が残りの予備領域の量、E9が残り寿命という噂は本当だったようです。
JSMonitorでの対応は可能ですが、E9の値の更新はかなり遅いので、結果が出るまでに相当な時間がかかりそうです。
大学の方で旧型160GBを使用しているのですが、半年近く使ってようやくE9が98になりました。このくらいならほとんど寿命を気にする必要がなさそうな予感もしますね…
>cuttingedgeさん
Intel新型は32MBのSDRAMを搭載しているみたいですね。
Intelの神様の話では、キャッシュが小さいから書き込み速度が出ない(どういう原理かはよく分かりません)+キャッシュが小さいから電源瞬断の対策もしてないということなので、新型もSDRAMは書き込みキャッシュには使ってなさそうな雰囲気です。
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch08a.html
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch08a.html
SSD(とTrim)の将来を考える上で参考になりそうな記事です
個人的には面白かったのでリンク貼っておきます
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch08a.html
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch08b.html
http://www.sun.com/storage/flash/module.jsp
これ自体にはNAND FLASHが4GBx8載ってますが見えるのは24GB分です。
知ってる限りEnterprise向けでMarvellはSunのこのモジュール等に88SS8014(3Gb SATA)というコントローラを供給してるはずです。(COMPUTEXでも同型番のコントローラを使用した2GB/s読み出しデモを公開してた様ですが)
その次世代版の試作品でしょうか。
興味深いですね。
現在の所は、VertexのTrimは効果はありそうなもののレスポンスが悪すぎて使い物にならないってことですね。
Windowsならごみ箱を消去しない限りTrimは発行されないみたいなので影響が少なそうな予感もします。
いずれしてもファームウェアアップデートで改善されればいいですね。
>kobagenさん
お、既にMarvell製のコントローラって存在してたんですね。
容量も少ないみたいですし、もしかするとSD88SA02もエンタープライズ向けかも?
http://www.jmicron.com/JMF612.html
http://www.jmicron.com/PDF/JMF612/JMF612.pdf
PDFにはNDA Requiredと書いてるのでお早めに・・・?
もし既出でしたらすみません
またConfidentialって書いてある文書がネットに上がってますね…
それはともかく、この性能は(本当なら)なかなかです。
250/200 MBytes/sec Sequential read/write rates (MLC)
6000/10000 IOPS 4K random read/write rates (MLC)
4Kのランダムリードが24MB/s、ランダムライトが40MB/sということなのでIntel並みですね。まあ多分瞬間最大風速なんでしょうが…
気になるのがJMF602同様に8chアクセスな点ですね。それでどうやって200MB/sの書き込みを実現してるんでしょう?
ところで、上記の文書の中で"Support maximum 16CE’s Flash per channel."とありますが、"CE"って何の略なんでしょう?所々で見かけるんですが結局分かりませんでした。どなたかご存じないでしょうか。
下記の資料にある制御信号の事ではないかと・・・間違ってたらすいません。
http://www.kyoto-sr.co.jp/products/fugue/techinfo/if-readwrite.html
TDKのコントローラの資料中にも出てきますね。「パッケージにより、接続チャネル数および実現容量が変わります。TQFP120の場合、2チャネル・インタリーブ接続、8CE接続可能、32GByte容量まで、VFBGA144の場合、4チャネル・インタリーブ接続で16CE接続可能、64GB容量まで実現可能です(MLC NANDの場合)。」
http://www.tdk.co.jp/tjfx01/jw_015_rs2.pdf
他の半導体の緒元見てみると電源マネージメントなんかの仕組みに
よく使われてるみたいですね
ウェアレベリングを気にし始めてから最近、デフラグツールの
ディスクの使用状況マップを良く見るのですが、SSDの最適状態とは、全体的にまんべんなく連続、不連続が混在している状態なのでしょうか?なかなか断片化されないのは、OSのシステムが連続的に入っている所とSSDの空き領域が連続している場所です
もしディスクの使用状況マップが物理的なアドレスを視覚的にちゃんと示していると仮定すると、データがバーグラフの領域確保部分全体にきれいに散逸しているのだと思うのですが如何でしょうか?とにかくウェアレベリングの状態が視覚的に確認出来るツール等が欲しいものです
勝手な想像ですが、1chあたりNANDフラッシュが最大16枚、トータルで128枚接続可能ってことでしょうか。上記サイトの/PDFディレクトリの下にあるJMF601や602のpdfをみるとそれぞれ64CEs、256CEsとなってますねぇ。また、パフォーマンスについてはJMF602(おそらく601も)での記載はSLCの場合のようです。JMF612でははっきりMLCと書いてありますが、単にSLCの間違いだとするとあまり違和感はないかも。
>piyopiyoさん
デフラグツールの分析表示は論理アドレスの断片化であって、物理アドレスでどうなっているかはコントローラが何か返してくれない限りOSからは見えないのでは?
う〜ん、やっぱりそうなのですかねぇ
パーテーションソフトで領域を確保するとき、スタートアドレスとエンドアドレスを入れて、論理的な形が崩れない様にすることが出来ますよね?そうした場合に、デフラグツールの分析マップで見ると、同じような形で断片化なしと診断されるんで、物理アドレスと重ねて考えてました...
あと、まっさらなSSDにOSをインストールしたときとかも、連続空間としてつながって表示しているんで何か相関性があるかと思ってました
また、電源ONにして2〜3日ほおって置くと連続空間表示のマップが少しずつ、刺しが入ったように変化してくるのだけれど、スタティックウエアレベリングの跡かなと眺めてたりしてました
いずれにしても少ないイレース場所の書き換えが見れる仕組みがあれば、いろいろ推測出来ると思うのですがなかなか難しいですね
悩ましいところです...
Cordwainerと言う者です(いつもJSMonitorを有り難く使わせてもらっています)。
横から口出しして済みませんが、私のSSDやNAND Flash Memoryに関する経験から言っても、SSDコントローラのスペックに出てくる "CE"とはNAND Flash Memoryの"Chip Enable"信号線(low active)の事で間違いないと思います。
DRAMやSRAM LSIで言うなら CS("Chip Select")信号線に相当するものですね。
参考資料:http://www.cqpub.co.jp/INTERFACE/sample/200703/I0703077.pdf
http://www.data-io.com/pdf/NAND/Toshiba/NandDesignGuide.pdf.pdf
(二番目の資料は図版が多少崩れているところがありますが、何とか読めると思います)
NAND Flash Memoryの種類によっては-CE及びRDY/-BSY信号を二組以上持つ変わったチップが存在するので、「xx個のFlash Memoryチップをサポート」ではなく「xx個のCEを接続可能」と言う表現になるのだろうと思います。
なるほど、ありがとうございました。
たとえばnCE=2の場合、チップ1枚の中に2組のフラッシュが存在していて、CEを切り替えることによってそれぞれのフラッシュにアクセスできるってイメージでしょうか…
うーむやっぱり実物を扱ったことが無いからよく分からんです。
>piyopiyoさん
cuttingedgeさんのおっしゃる通り、論理アドレス(OSから見えるアドレス)の状態から物理アドレス(SSDコントローラが管理しているアドレス)の状態を推測するのはほぼ不可能です。
論理アドレスのレベルでファイルが整然と並んでいたとしても、物理アドレスの並び順は滅茶苦茶ということもありえます。また、スタティックウェアレベリングが発生しても、あくまでコントローラが勝手に物理アドレスの位置をスワップしているだけなので、論理アドレスレベルでは何も変わっていないように見えます。
データ=手紙、コントローラ=郵便局、OS=手紙の送り主、論理アドレス=宛名、物理アドレス=住所という例えを用いると分かりやすいです。
送り主(=OS)は手紙(=データ)に「佐藤さん宛て(=論理アドレス上の位置)」と書いて投函する(=書き込む)と、郵便局(=コントローラ)がわざわざ佐藤さんが3丁目2番地(=物理アドレス上の位置)に住んでいるのを調べて正しく手紙が届けられる、というイメージです。
送り主は50音順に「佐竹さん」→「佐藤さん」→「里中さん」と連続して手紙を送っても、彼らの家が隣同士になっているとは限らないので、たとえば2丁目の佐竹さん→6丁目の佐藤さん→5丁目の里中さん、という感じに全然別の場所に手紙を届ける必要があるかもしれません。
この例で言うと、たとえばIndilinxのIdle GCやWiperは、手紙がこなさそうなタイミングで佐竹さんと佐藤さんと里中さんの家が隣り合わせになるように強制的に移住させるようなものです。それが起きても、送り主的には佐竹さんの次は佐藤さんで、その次は里中さんという50音の順序は変わらない訳で、なぜか手紙が全部届くまでの時間がこの前より短くなっている、という現象が起きます。
CEの件、既出の質問にも関わらずデフラグに関して、丁寧に説明して頂きありがとうございます
恥ずかしついでにもう一つ教えて下さい
デフラグの行為自体は、ヘッドのシーク時間を短縮するために、断片化したファイルブロックの物理アドレスを繋げる事と思うのですが、デフラグツールでデフラグを実行後、デフラグツールのマップで確認すると、データが綺麗に繋がって表示されます、これから論理、物理のアドレス間には何かしらの相関があると感じるのですが間違いでしょうか?
あと、本日X-25Mのシステムドライブを立ち上げっぱなしにしておいた所、朝Defragglerでの断片化率が12%だったのに、8時間後にはマップの模様が微妙に変わっていて、断片化の割合が8%に減っていました
スタティックウェアレベリングとしか思えないのですが、皆さんはいかがお考えですか?質問ばかりでごめんなさい、教えて下さい
HDDの場合は、物理構造とアドレス配置が一致しているため、論理アドレスレベルでデータを直列化すれば、物理的な並びも直列化されます。
http://pc.nikkeibp.co.jp/article/trend/20081210/1010463/?SS=pco_imgview&FD=-19752494
この右側の図がわかりやすいと思います。LBAはディスクの回転方向に1つずつ増えていき、一周回り終わると一つ内側のトラックに移動します。データが直列に並んでいれば、ヘッドは連続的にアクセスを行うことができます。一方、ランダムアクセスを行う場合、目的のデータがヘッダの所に回ってくるまで待たないといけないので、数msは無駄な時間ができてしまうわけです。
Defragglerの断片化率のことはちょっと分からないですね…
ただ少なくともスタティックウェアレベリングで論理アドレスが変更されることはないので、たまたま新しく書き込んだデータが隙間を埋めたとかが原因ではないでしょうか?
Windowsの自動デフラグは無効化されてますか?
まいどです、piyopiyoです
早速のご教授ありがとうございます
HDDの場合はpiyopiyoの理解しているシーケンスとほぼ同じ事がわかりました
SSDは複雑ですね、もう少し勉強してみます
Windowsの自動デフラグ自体は無効にしていますが、やはり何がしかの書き込みが原因でしょうか?
今後も観察してみます
X-25Mは安定しているのですが、何かつまらないですね
50nmモデルは今後Trimの提供も無いみたいですし、S592じゃないですけど何か見放され気分です
その点VertexはJSMonitorもTrimも使え、数値の反応も大きいので、使っていて楽しいです
BaerfootコントローラはぜひWin7に対応してもらいたいものです
まずはご教授のお礼まで..
自作erの性というか、システムが安定してると逆に何か物足りないってのはありますね。分かっていてもキワモノっぽいのに手を出してみたくなります。まあ、Indilinx系は壊れない限り使い物にはなるので、プチフリでイライラするJMF602よりは遙かにマシです。
趣味なら不安定も良いですけど、あまりにひどいと腹立ってきますよ(笑)
仕事だと関係のものだと尚更です。
ちなみにTrimですが、今後発売するモデルでは、全社がTrim対応と
なることがほぼ決定事項です。
なんせ、WHQLの項目に乗る予定らしいので、Windowsのロゴマーク
取得を取得するためにTrim対応が必須になる可能性が高いのです。
今は、まだ、必須ではないらしいですが、来年春ぐらいに、必須
項目になるとかならないとか聞いています。
自作用ならまだしも、PCOEMでは、WHQLを取得していないと採用し
てもらえませんからメーカーは死活問題です(政治的ですよね)
ただし、Trim対応しているからと言って、受け取った情報を活用し
ている保証はありません。HostにOKだけ返して、捨ててる可能性も
当然あります。なので、Trimに対応したからと言って何の変化も
みられない場合も当然あると思います。
ちなみに、JMF612ですが、Crystalでリードは250MBぐらい、ライト
で150MBぐらいでます。4Kは、リードライトとも18MBぐらいです。
現状では、Indilinxぐらいの性能です。ファームのできがいまいち
らしいという話なので、ファームアップでライト性能はまだ向上す
るようですが。
X-25Mの件、プチフリや不安定がない分満足しなくては!ですね..
前のVertex250Gは突然死んでしまい、大変な目に合いました
先日新品になって戻って来ましたが、もう使用する気持ちにはなれません
今は、X-25MとVertex60Gを主に使用しています
Vertex250Gは良い話を聞かないですね、まさかパワー素子ではないのでラッチアップ等は起きないでしょうが、おそらく電源シーケンス等の微妙なズレで内容が消えたり、動作しなくなってしまうのではないかと思います(250Gモデル特有の現象でしょうか?)
待ちに待ってるJMF612は楽しみですね、ウェアレベリングに関してはJMicronが一番まともな動きをしているように見えます、あとはLight Amplificationの値ですかね?
ウェアレベリングですが、基本的にがんばるとパフォーマンスは
劣化する傾向になるかと思います。均一度を増すと、それだけ、
複雑なことをすると思いますので。
たとえば、Windowsのシステムファイルのようなデータの場合、
物理アドレスの先頭から順番に埋めてしまうと、そのエリアのみ
ほとんど書き換えが発生しないことになり、他の部分にデータの
書き換えが頻発することになります。このため、どこかの次点
で、スタティックウェアレベリングを発動させ、適当に移動さ
せないと寿命が低下してしまいます。
これをSSDの記録がページ単位、消去はページを複数まとめたブ
ロックというある意味デメリットをうまく利用して、上手に散
らして記録できれば、少なくとも書き換え頻度をある程度均一
に保てます。たとえば、書き換え使用頻度が少ないファイルの
一部分を書き換え頻度が高いエリアに混ぜておくと、書き換え
頻度が高い低いに関係なく、そのエリア内のデータを書き換え
ると自動的に消去ブロック内のデータは、すべてどこか別のブ
ロックに移動されるかテンポラリにコピー後同じブロックに書
き戻されることになります。
これによって、結果的にスタティックウェアレベリングを発動
することなく、書き換え頻度の均一性をある程度保てるという
わけです。
上記をそのまま適用すると、かえって寿命を縮めかねないので
現在のSSDは、もっと考えてやっていると思いますが・・・。
また、Trimにしても、不要な場所のみを教えるのではなく、
たとえば、WindowsのEXEファイルやDLLのように、一度記録した
ら、ほとんど書き換えることがないようなファイルの情報を記録
時に教えてくれるというなら良いのですが、実際には、そのよう
なものではありません。
更にTrimの悪口を言わせてもらえるなら、仕様上、4KB単位で不
要なアドレスを通知するようですが、ストレージの容量が大きく
なるに従って、それを管理するための情報を保存するためのメモ
リも大きくなります。SSDでは、ウェアレベリングを効率的に行
なうために、記録の履歴をメモリ上にそれなりに保存している
はずですから、あまり管理情報を増やしても必要なメモリが肥
大化するだけで、かえってパフォーマンスが低下するなんてこと
もあるかもしれませんね。
NAND Flash Memoryの特性と言うか書き込み時の制約を考えるとマーキング情報をどこにどうやって保持しておくべきかはなかなか悩ましい問題だという気もします。
まじめに効率的な方法でインプリメントしようとすると各社ともこれまでのNAND Flash Memoryの管理方法を根本から考え直す必要があるのかも知れませんね。
Indilinxは現在のフラッグシップであるBarefootコントローラーのFWのアップデート、Win7対応まで引き続きがんばって欲しいものです
X-25M、G1に関しては”神様”が見放しちゃったんで、如何ともしがたいです、実は会社でX-25M、G2を使用しているのですがベンチマークの値はともかく、実使用感はG1よりももっさりしています
なんと言うかG2よりもG1と045C8820のFWの方がなんかしっくり行ってる感じがします
G2はやはりさらなるFWのアップデートが必要なのかな?と考えています
まずは秋に出るといわれている「SSD Toolbox」とやらと、Trimツールの出来を確認してから、自宅にもG2導入をと考えていました
しかし個人的には現行のYatapdongさんにも頑張ってほしいんです(かくれIndilinxファンなので..)早く1711の正式版をためしてみたいです
ガーベージコレクション(GC)ですが、すべてのメーカーが積極的に
行なっているわけではないようです。
僕の知る限り、T社製SSDでは、基本GCは発動させない方針で設計され
ています。(その分、性能が微妙な感じになってしまっていますが)
技術者の方いわく、GCも発動させさせるとそれだけパフォーマンス
が低下し、書き換え回数も増加するため、寿命に影響がでるとのこと。通常、GCは、アイドル時にやると思いますので、実際のところ
は、寿命への影響が大きいということなのでしょう。
現状のSSDで最大限寿命を長く取るためには、スタティックウェア
レベリングの発動やGCの発動は、書き換え回数の増加を招き、寿命
低下の原因に直結するためできるだけ避けるべきというわけです。
ただ、ダイナミックウェアレベリングで頑張るためには、将棋の先
読みと一緒でそれなりに時間をかけて計算する必要がでてきます。
結果、レスポンスタイムに影響がでてしまい、性能が低下する。
これが、T芝製SSDの性能が伸びない要因の1つだと推測されます。
Trimにしても、情報の受信、即座にGC実行というのも、書き込み
の増加を招くだけで、結果的に寿命面に関しては不利になるだけ
という可能性も否定できません。
また、ためておいて利用する場合でも、それが本当に効率的な管理
に結びつくのか未知数です。実際、現状のアルゴリズムで適用して
も効果無しと言い切ってしまうメーカーもいます。
まあ、いずれにしてもしばらくは楽しめそうです。
>なんと言うかG2よりもG1と045C8820のFWの方がなんかしっくり行っ
>てる感じがします
G2ですが、平均的なレスポンスタイムがG1のときよりも長めなって
いるからではないかと思います。
先月G2でIOMeterを何回もやりましたが、MaxResponseTimeが200msを
切ることはありませんでした。SecureEraseをやっても変化なしで
す。G1のときは、比較的簡単に100ms台が簡単にでたのですが、それ
とは大違いです。
あくまで個人的な想像ですが、G2は、採用したNANDメモリの書き換え
回数が減ったので、それに応じて、ダイナミックウェアレベリングを
強化し、その影響が、平均的なレスポンスタイムの増加に繋がってい
るのではないかと思っております。
結果として、平均的なレスポンスタイムが長いG2がもっさりしている
と感じるのではないでしょうか。(あくまで僕の想像です)
>先月G2でIOMeterを何回もやりましたが、MaxResponseTimeが200msを切ることはありませんでした。
先月末のAnandtechのレビューでも同様なデータが示されてますね。
http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=4(4番目の図; 私が、再出荷された後も今までG2の入手を見合わせている理由の一つがこれです。)
同記事の解説によればMax Res Timeの正体はリアルタイム?のブロックコピー・ガーベジコレクション(BC/GC)のようで、G2ではこれに手間取っている感じでしょうか。実際の使用では所要時間の長さもさることながらその発生頻度が問題なのでしょう。ごく稀にしか発生しないようであればあまり問題はないと思いますが、高頻度ではレスポンスが悪くなる要因ですね。極端な例はLansenさんのこのBlogのプチフリメカニズムについての一連の記事にあるJMF602ですね。 昨年の発売直後にX25-E (FW8621)でちょっと検討しかけたことがありますが、その後いろいろ情報も増えてきたので条件を整えてもう少し深く追求してみると面白いかも・・・ http://cuttingedge.blogzine.jp/blog/2008/11/x25e_3_1520.html
X25-E/Mのコントローラの場合、HDDErase後の未割り当て領域の確保でそこも予備領域(フリーブロックのプール)として使うようなので、そのことによりリアルタイムBC/GCの発生が減少するとすれば、レスポンスも良くなり、結果的にWrite Amplificationも小さくなるし、性能低下が起こりにくくなるのではないかと想像してます(要検証)。
私見ですが、X25-E/Mではよほど洗練された実装でない限りバックグランドのTRIM/GCは不要かなと感じてます。予備領域の確保とHDDerase後のバックアップイメージの復元との組み合わせで行うユーザー主導の管理の方が好ましいですね。
>Trimについて
DOS/V Power Reportのインタビューでは、東芝のSSDは「フラグメントが発生しにくいので、長期使用に伴う性能低下が起こりにくい」「Trimで得られる効果のかなりの部分を既に実現できている」とのことなので、Trim対応になっても大して差がないSSDの筆頭になる可能性がありますね。東芝はどうやら他のコントローラメーカと違って目に見えにくいところに力を入れてる感じで、実際に体感は良いのかもしれません。
IntelのSSDは320GBまで予定されているようですが、320GBを4KBで区切ると80,000,000個もの領域に分かれてしまうので、例えば1個の領域あたり1Byteのデータが必要とすると、合計で80MBになってしまいます。かなりうまくやらないとコントローラがデータを裁ききれなくなりそうです。SDRAMが16MBしかない旧型IntelがTrim対応しないというのもこの辺に理由があったりするかも?
>新型Intelのパフォーマンス
Avg Latencyはほとんど変化がないので、体感には影響しないだろうと思ってました。やっぱり一回ごとのレスポンスタイムをグラフなりヒストグラムなりにしてくれるベンチマークソフトが欲しいところですね。そろそろ誰か作ってくれるかと思ってたんですが、なかなか出てこないです。もう自分で作るしかない?
>marosamaさん
JMF612は既にベンチマークが公開されているんでしょうか?
ちょっとググった感じだと見当たらなかったです…
>東芝はどうやら他のコントローラメーカと違って目に見えにくいところ
>に力を入れてる感じで、実際に体感は良いのかもしれません。
東芝製SSDを使われたことがあるかたはほとんどいないと思いますが、
実際のところ、体感そのものは、悪くはありません。他社と比較し
てもっさりしている感じがするのは事実ですが。
ただ、通常の使用でベンチマークの数字の違いほど遅いかというとそ
んなことはありません。現状で個人的に感じているのは、不得手な部
分がありそうだということです。
あくまで個人的な印象ですが、Video編集系の操作は向いていないよう
で、ちょっと遅いと感じるときがあります。通常の使用では、特に不
満はありません。
メーカーもその当たりは、解っていますので、おそらく次期製品では、
ベンチマークでももう少し数字がでるようになると思います。
東芝製品は、現行の2世代目の製品よりも、3世代目のほうががバラン
ス的に良さそうな気がします。
>JMF612は既にベンチマークが公開されているんでしょうか?
まだかもしれませんが、そのうち出てくると思います。
たとえば、今月29日発売のパワレポさんとかです。(笑)
最後に、パワレポを読まれたなら、IntelのSSDのフラグメント発生
状態の激遅ベンチマークがでていたと思います。
あれの作り方を知りたい人っていますか?
掲載スペースの関係で、作り方は省略されていますが、要望があれ
ば、作り方をお教えできます。作るのに8時間ぐらいかかりますけど。
X-25Mに関してのもっさり感はpiyopiyoの体感もあながち勘違いでもなかったのですね...
自宅導入の前に会社でヒトバシラーになってもらったのですが
”う〜む”と言う感じでしたので、現在自宅導入はペンディングとしております
>SDRAMが16MBしかない旧型IntelがTrim対応しないというのも..
了解です、Intelのお家芸はアクロバチックなダイナミックウエアレベリングのはずなのですが、ハードがついて来ないのでは如何ともしませんね、引き続きレスポンスの変化を見てみたいと思います
>たとえば、今月29日発売のパワレポさんとかです。(笑)
今月のパワレポ楽しみです、MJF612ですが50nmのNANDフラッシュとの組み合わせで出てくる可能性は残っているのでしょうか?
初回から30mm次世代からの組み合わせであるとするともう少し出るまで時間が掛かりそうな気がしてます
>Avg Latencyに関して
ダイナミックウエアレベリングを如何に巧く処理するかが肝要になるようですね、DLLやEXEファイルの認識は無理としても、領域確保の時点で物理アドレスと論理アドレスを巧く離散させることが出来ればMinimam Erace Countを意図的に増加させることが出来るのではないでしょうか?
>ALL
いろいろ考えているとまたIndilinxコントローラ搭載機種に趣向が戻ってしまいます、FWのUPや、Trim0525などユーザーが容易に体感できるのがVertex(Indilinx)の良い所だと思います
piyopiyoはまだ250G1個しか死んでないのですが
Max Erace Countが10000回を超えて寿命を全うしたユーザーがまだ現れていないので、自宅でメイン機種にするかどうか決めかねています、もしもVertexが予想以上に寿命が長く、Win7のTrimに対応するとしたら、現時点で一番買いのような気がしてます
それにしても、パソコン暦長いのですが、ここに来てこんなに面白い状況が来るとは思いませんでした
昔のように多少ワクワクしますよ
今後の業界の動向が楽しみです
「現行の2世代目」っていうのが例のDynabook SSに入っているシリーズですよね。
もう次世代の製品ができはじめてるってことでしょうか?
フラグメント状態の作り方はぜひ伺いたいです。あの記事を読んだときは、デフラグ前の状態の作り方はどこに乗ってるのかなあと思って三回ぐらい本文を読み直してしまいました。
>piyopiyoさん
http://www.dailytech.com/SSD+Prices+Could+be+Cut+in+Half+Due+to+New+JMicron+Flash+Controller++32nm+NAND+Flash/article14176.htm
↑のDailyTechの記事では、32nmのフラッシュとの組み合わせで価格を現在の半分にするとありますね。
具体的にはやはりSamsungのFlashのようですが、もう量産されてるんでしょうか?
>もう次世代の製品ができはじめてるってことでしょうか?
そうなるかと思います。
通常の製品開発では、現行の製品のサンプル出荷開始の段階で、すでに
次の製品の開発も進行しております。
現行製品が、春から夏にかけてのPCへの搭載であったことを考えると、
次の世代のサンプル出荷開始は、おそらく、年末。正式な出荷は、現行
製品と同時期となると予想されます。
>フラグメント状態の作り方はぜひ伺いたいです。
了解です。
基本的な考え方は、フラグメントを強制発生させるためにデータのライトと
消去を繰り返しただけです。ただ、実環境では、まず、このような使われ方
はないと思います。手順は、以下の通りですが、作成に当たっては、任意の
サイズのダミーデータ(データの中身は何でもOKです)を作れるソフトを準
備してください。また、ファイルの作成は、ルートにテスト用のフォルダを
1つ作って、その中に更にサブフォルダを順番に作成し、ファイルの作成と削
除を繰り返すというやり方で行なっています。
たとえば、ルートに「Test」というフォルダを作成し、Testの中に[1]という
サブフォルダを作成、ファイルのコピー、削除、終わったら、次は、[2]と
いうサブフォルダを作成、ファイルのコピー、削除。という感じで空き容量
が4GB前後になるまで繰り返し行なっています。なお、これだけでは、足りな
いと考え、途中で256MBと128MBという少々大きめなファイルの作成、削除行っ
ています。
1.VistaSP1をインストール。SP2へアップはなし、WindowsUpdateも無しです。
2.OSのインストールが終わったら、VistaをインストールしたSSD以外から起動
します。
3.作業フォルダのルートに256MBのファイルを作成し、サブフォルダを作成。
1K〜1000KBの計1000個のファイルを作成。
奇数KB(1KB,3KB,5KB...という感じです)のファイルを削除。
4.作業フォルダのルートに128MBのファイルを作成し、サブフォルダを作成。
1K〜1000KBの1000個のファイルを作成。
偶数KB(2KB,4KB,6KB...)のファイルを削除。
5.[3.]で作成した256MBのファイルを削除し、サブフォルダを作成。
1K〜1000KBの1000個のファイルを作成。奇数KBのファイルを削除。
6.[4.]で作成した128MBのファイルを削除し、サブフォルダを作成。
1K〜1000KBの1000個のファイルを作成。偶数ファイルを削除。
7.Intelの160GBSSDの場合は、3.〜6.までの手順を470個のサブフォルダが
できるまで繰り返します。空き容量4GB前後となるはずです。
128GBのSSDの場合は、437個作成すれば、空き容量がやはり4GBぐらいとな
ります。
8.256MBまたは128MBのファイルが残っているときは、それを削除し、
一番数字が大きいフォルダから1つ飛ばしでフォルダを40個削除。
この状態で空き容量が約14GBぐらいになると思います。
9.フリーソフトのデデフラグというソフトを実行。
以上で完成です。僕は、面倒なのでバッチファイルで回しましたが、
128GBの場合で、8.手順までで、3〜4時間ぐらいはかかります。トー
タルでは、6〜8時間ぐらいはかかるので、暇なときにやるとよろしい
かと思います。
今思えば、最初のVistaインストールは不要だと思いますが、時間的な
制約から、引き返せませんでした。(〆切あるんで)
また、このテストで、Indilinxの石を搭載したSSDがテストの最後の方
でお亡くなりになったことも付け加えておきます。
なるほど、大分手間がかかってますねえ…
僕が最初にフラグメント時のベンチマークを掲載したときには、単純にランダムサイズのファイルをディスクが埋まるまで作り続け、最後に奇数番号のファイルを削除しただけでした。
Vertexでもデフラグの効果について調べようと思ってたんですが、わざわざHDDEraseをやらないといけないのが面倒でサボってました。でも、最近OCZが公開しているSanitary_Eraseを使えば簡単にSecure Eraseができるので、来週末ぐらいにチャレンジしてみようかと思っているところです。
ちなみに、東芝が自作PC用に出そうとしているSSDってのは、その第三世代の製品なんでしょうか?そうだとするとまだしばらく時間がかかりそうですね。
>やっぱり一回ごとのレスポンスタイムをグラフなりヒストグラムなりにしてくれるベンチマークソフトが欲しいところですね。そろそろ誰か作ってくれるかと思ってたんですが、なかなか出てこないです。もう自分で作るしかない?
多分待っても出てこないんじゃないでしょうか。
私には作れませんからぜひ!!
それにしても、SSD は切り口がありすぎて性能評価も本当に難しい
ですねぇ。
最近CrystalDiskInfoの報告を全然してなくて申し訳ありません。ちょっと今出張中なので、帰ったらということで…
Iometerのソースも公開されてますし、実際のところストレージ用ベンチマークソフトを作るにあたって技術面ではそれほど超難易度ではないと思います(この認識の時点で勘違いモードな予感も若干しますが)。
問題はUIの方で、結局ただのHD Tuneの劣化版みたいなのを作っても仕方ないよなあ〜と思うわけです。最近XAMLなるものを勉強し始めたのですが、それを使えば結構面白いのができるかも?という妄想はふくらみ中です。あ、これは作るという宣言じゃないですよ?
是非お願いします。インテルX25-Eを用いてIometer(全容量の1/4の領域に5秒間の4Kランダム書き込みを連続30回行う方法)で、一度も書き込んでない領域の割合の影響をみるデータを取ってみたのですが、CSVファイルから手作業でグラフ化するのが面倒で放置状態になってます・・・
>なるほど、大分手間がかかってますねえ…
はは。テストに手間だけはかかっています。
最近のSSDは、予備ブロックを含むすべての物理エリアを使って当初から
データの記録を行なっているため、物理アドレスの断片化による速度低下
を引き起こすには、最低でもSSDの記録容量の1.1倍以上のデータを記録し
ないと意味がないと考え、入念にデータを散らしてみました。
おかげで凄い時間がかかることになりましたが・・・。
>東芝が自作PC用に出そうとしているSSDってのは、その第三世代の製品
>なんでしょうか?そうだとするとまだしばらく時間がかかりそうでね。
いつから発売するかによるのではないでしょうか。
年末というなら、現行商品でしょうし、来年春なら、第3世代が濃厚かと
思います。
>という妄想はふくらみ中です。あ、これは作るという宣言じゃないで
>すよ?
ぜひ、お願いしたいところです。
うーむ、作るとしても年末年始とかですかね…
そんなすぐに完成しそうな予感は全然しないので、まあ期待しないで待っていてください…
あとBenchmarkreviewの記事ではSATA-6G対応M/Bであまり良い結果が出ていませんが、ドライバが未完成ってことでしょうか?http://benchmarkreviews.com/index.php?option=com_content&task=view&id=413&Itemid=38&limit=1&limitstart=1
MicronのデモのSATA-6Gカードではそれほどは悪くなさそうですし。
こちらでは、あまり厳密には測定してないのですが、P55 Deluxe本体に接続したときとSATA3Cardに接続したときではほとんど同性能で、違いはTrimがあるかないかぐらいでした。
こんどもう少し調べておきます。