CrystalDiskInfoやCrystalDiskMarkなどCrystal Dew World製品に関する総合掲示板です。
 |
 |
CrystalDiskMark 6.1.0 Beta1 について 金華山の仙人 17/11/30(木) 16:07 |
|
|
Re:CrystalDiskMark 6.1.0 Beta1 について 金華山の仙人 17/11/30(木) 16:27 |
![[添付]](./brd/myk/image/clip_icon.gif){kind=icon}
|
|
 |
Re:CrystalDiskMark 6.1.0 Beta1 について 金華山の仙人 17/12/1(金) 0:29 |
|
|
|
Re:CrystalDiskMark 6.1.0 Beta1 について marosama 17/12/8(金) 21:47 |
|
 |
Windows上のDiskMarkで有る限り、やはりデフォルトは... 金華山の仙人 17/12/9(土) 2:08 |
|
|
Re:Windows上のDiskMarkで有る限り、やはりデフォル... marosama 17/12/10(日) 12:07 |
|
|
Re:Windows上のDiskMarkで有る限り、やはりデフォル... hiyohiyo 17/12/10(日) 23:48 |
|
|
Re:Windows上のDiskMarkで有る限り、やはりデフォル... marosama 17/12/12(火) 2:45 |
|
|
Re:Windows上のDiskMarkで有る限り、やはりデフォル... hiyohiyo 17/12/13(水) 0:53 |
|
|
Re:Windows上のDiskMarkで有る限り、やはりデフォル... marosama 17/12/13(水) 7:52 |
|
|
Re:Windows上のDiskMarkで有る限り、やはりデフォル... hiyohiyo 17/12/14(木) 1:22 |
|
金華山の仙人 - 17/11/30(木) 16:27 - |
因みに、これはウチのAMD環境でほぼ唯一シーケンシャルReadが500MB/s未満になったSSDですが、CDM6.1だと普通に500MB/s以上が出ました。
（Palit GFS は S11コン＋ 3D MLC です。）
最高スペックを検出する、というCDMの目的からすればブロックサイズ2MiBの方が良いのでしょうが、過去データとの比較には宜しく無いかと。
但し、もしブロックサイズ2MiBの方が、実用時の動作に近いのなら、一考の余地は有りますが、どうなんでしょう？
（Palit GFS は S11コン＋ 3D MLC です。）
最高スペックを検出する、というCDMの目的からすればブロックサイズ2MiBの方が良いのでしょうが、過去データとの比較には宜しく無いかと。
但し、もしブロックサイズ2MiBの方が、実用時の動作に近いのなら、一考の余地は有りますが、どうなんでしょう？
|
金華山の仙人 - 17/12/1(金) 0:29 - |
補足：
因みに、CDM5.2.2の単なるシーケンシャル（ブロックサイズ=1MiB、Q=1）の測定結果でも、先のシーケンシャル（ブロックサイズ=128KB、Q=32）よりも低いので、Q数が少ないと大ブロックサイズでも好成績にはなってません。
因みに、CDM5.2.2の単なるシーケンシャル（ブロックサイズ=1MiB、Q=1）の測定結果でも、先のシーケンシャル（ブロックサイズ=128KB、Q=32）よりも低いので、Q数が少ないと大ブロックサイズでも好成績にはなってません。
|
marosama - 17/12/8(金) 21:47 - |
▼金華山の仙人さん：
>但し、もしブロックサイズ2MiBの方が、実用時の動作に近いのなら、
>一考の余地は有りますが、どうなんでしょう？
実際にドライブに送られるRead/Writeのコマンドベースで
考えるなら、128MiB以下のサイズでしか一部の例外を除い
て送られることはありません（Windowsでは、USAPの場合は、
最大512KiBのサイズで送れます）。
なので、それを実用ととるなら128MiBでよいと思います。
ただ、OS上からアプリでという想定なら、2MiBという考え
方もありだと思います（256MiB以上のサイズがでるという
わけではありません。デバドラの仕様で、SATA/NVMeに関し
てはWindowsでは、128KiBが最大サイズです。）
>但し、もしブロックサイズ2MiBの方が、実用時の動作に近いのなら、
>一考の余地は有りますが、どうなんでしょう？
実際にドライブに送られるRead/Writeのコマンドベースで
考えるなら、128MiB以下のサイズでしか一部の例外を除い
て送られることはありません（Windowsでは、USAPの場合は、
最大512KiBのサイズで送れます）。
なので、それを実用ととるなら128MiBでよいと思います。
ただ、OS上からアプリでという想定なら、2MiBという考え
方もありだと思います（256MiB以上のサイズがでるという
わけではありません。デバドラの仕様で、SATA/NVMeに関し
てはWindowsでは、128KiBが最大サイズです。）
|
金華山の仙人 - 17/12/9(土) 2:08 - |
▼marosamaさん：
#1150 の書込みは、
128MiB ｘ ⇒ 128KiB ○
256MiB ｘ ⇒ 256KiB ○
という理解で良いでしょうか？
あとWindowsのSATA/NVMeデバドラの仕様が、最大128KiBが本当なら、（恐らくRAIDドライバ仕様の）2MiBをデフォルトにするのは、やはり止めて頂くしか無さそうですね。
OSからAPLなら2MiBが有りだとしても、それはAPL依存＝環境依存(RAID含む）になってしまうから、（私から見て）単純明快なストレージの性能測定ソフト、というCDMの位置付けから外れると思いますし。
#1150 の書込みは、
128MiB ｘ ⇒ 128KiB ○
256MiB ｘ ⇒ 256KiB ○
という理解で良いでしょうか？
あとWindowsのSATA/NVMeデバドラの仕様が、最大128KiBが本当なら、（恐らくRAIDドライバ仕様の）2MiBをデフォルトにするのは、やはり止めて頂くしか無さそうですね。
OSからAPLなら2MiBが有りだとしても、それはAPL依存＝環境依存(RAID含む）になってしまうから、（私から見て）単純明快なストレージの性能測定ソフト、というCDMの位置付けから外れると思いますし。
|
marosama - 17/12/10(日) 12:07 - |
▼金華山の仙人さん：
>▼marosamaさん：
>
>#1150 の書込みは、
>
>128MiB ｘ ⇒ 128KiB ○
>256MiB ｘ ⇒ 256KiB ○
>
>という理解で良いでしょうか？
すみません。書き間違えてました。
128KiBと256KiBでOKです。
厳密には、Sector単位で、256Sectorと512Sectorです。
AFTとはいえ、現状は、512バイト/Sectorなので、128KiBと
256KiBになります。
ネイティブ4Kのドライブだと話が変わりますが、現状、
ネイティブ4Kのドライブは、市販ではみないので。
>あとWindowsのSATA/NVMeデバドラの仕様が、最大128KiBが本当なら、
>（恐らくRAIDドライバ仕様の）2MiBをデフォルトにするのは、やはり
>止めて頂くしか無さそうですね。
僕がチェックした限り、128KiB（256Sector）が最大転送ブ
ロック長です。このあたりは、過去とのしがらみがあるので、
多少効率が悪くても、しょうがないようです。
ちなみに、IntelのRAIDドライバーも128KiBですよ。
>▼marosamaさん：
>
>#1150 の書込みは、
>
>128MiB ｘ ⇒ 128KiB ○
>256MiB ｘ ⇒ 256KiB ○
>
>という理解で良いでしょうか？
すみません。書き間違えてました。
128KiBと256KiBでOKです。
厳密には、Sector単位で、256Sectorと512Sectorです。
AFTとはいえ、現状は、512バイト/Sectorなので、128KiBと
256KiBになります。
ネイティブ4Kのドライブだと話が変わりますが、現状、
ネイティブ4Kのドライブは、市販ではみないので。
>あとWindowsのSATA/NVMeデバドラの仕様が、最大128KiBが本当なら、
>（恐らくRAIDドライバ仕様の）2MiBをデフォルトにするのは、やはり
>止めて頂くしか無さそうですね。
僕がチェックした限り、128KiB（256Sector）が最大転送ブ
ロック長です。このあたりは、過去とのしがらみがあるので、
多少効率が悪くても、しょうがないようです。
ちなみに、IntelのRAIDドライバーも128KiBですよ。
|
hiyohiyo
- 17/12/10(日) 23:48 -
|
▼marosamaさん：
>僕がチェックした限り、128KiB（256Sector）が最大転送ブ
>ロック長です。このあたりは、過去とのしがらみがあるので、
>多少効率が悪くても、しょうがないようです。
>ちなみに、IntelのRAIDドライバーも128KiBですよ。
http://blog.livedoor.jp/wisteriear/archives/1068179824.html
にあるように、ATTO Disk Benchmark でブロックサイズを変更して評価すると非 RAID 時は 128KiB でほぼ頭打ちとなっているのですが、RAID 時はブロックサイズの拡大に合わせ速度が出ています。8枚 RAID の場合 2MiB で頭打ち。
ストライピングサイズの関係があるのかもしれませんが、128KiB x8 で考えると 1MiB で十分な気もします。
この理由何か考えられそうなことあるでしょうか。
また、そもそも 128KiB x 32Q で実行していれば、データ供給量としては十分な気もするのですが、ブロックサイズ拡張することでベンチマーク結果が良くなる理由も正直なところよくわかっておりません。
アプリから 2MiB ブロックでコマンドを送れば、ドライバで 128KiB x 16 に分解してドライブにコマンドを送るものと理解しているのですが、そんな単純なものではないのでしょうか。
ATA コマンドなり、NVMe コマンドまでトレースできるようなソフトウェアなりハードウェアを使って、実際の状況を確認してみるのが一番だとは思うのですが、そこまでの知識もなく。。。もしご存知でしたらご教示いただけないでしょうか。
教えていただいてばかりで申し訳ございません。
>僕がチェックした限り、128KiB（256Sector）が最大転送ブ
>ロック長です。このあたりは、過去とのしがらみがあるので、
>多少効率が悪くても、しょうがないようです。
>ちなみに、IntelのRAIDドライバーも128KiBですよ。
http://blog.livedoor.jp/wisteriear/archives/1068179824.html
にあるように、ATTO Disk Benchmark でブロックサイズを変更して評価すると非 RAID 時は 128KiB でほぼ頭打ちとなっているのですが、RAID 時はブロックサイズの拡大に合わせ速度が出ています。8枚 RAID の場合 2MiB で頭打ち。
ストライピングサイズの関係があるのかもしれませんが、128KiB x8 で考えると 1MiB で十分な気もします。
この理由何か考えられそうなことあるでしょうか。
また、そもそも 128KiB x 32Q で実行していれば、データ供給量としては十分な気もするのですが、ブロックサイズ拡張することでベンチマーク結果が良くなる理由も正直なところよくわかっておりません。
アプリから 2MiB ブロックでコマンドを送れば、ドライバで 128KiB x 16 に分解してドライブにコマンドを送るものと理解しているのですが、そんな単純なものではないのでしょうか。
ATA コマンドなり、NVMe コマンドまでトレースできるようなソフトウェアなりハードウェアを使って、実際の状況を確認してみるのが一番だとは思うのですが、そこまでの知識もなく。。。もしご存知でしたらご教示いただけないでしょうか。
教えていただいてばかりで申し訳ございません。
|
marosama - 17/12/12(火) 2:45 - |
▼hiyohiyoさん：
>▼marosamaさん：
>ストライピングサイズの関係があるのかもしれませんが、128KiB x8 で考
>えると 1MiB で十分な気もします。
>この理由何か考えられそうなことあるでしょうか。
ストライピングサイズとの関係はあるのではないかと思います。
僕の記憶ですと、2台でRAID0を構築した場合で、現在のSSDならストライピ
ングサイズ32KB以上がよかったと記憶ししています。
16KBとかに設定すると、128KiB QD32 T1のリード速度が32KB/64KBのときと
比較して、2割ほど遅くなりました。
そのときの128KiB QD32 T1と4KBのリード/ライトの速度は、誤差範囲の違い
でしかありませんでした。
128KiB QD32 T1でリード/ライトが最大になるようにストライビングサイズ
を調整して、ベンチを行うともしかしたら、2MiBなどのブロックサイズでも
変化がなくなるとかあるような気がします。
>アプリから 2MiB ブロックでコマンドを送れば、ドライバで 128KiB x 16
>に分解してドライブにコマンドを送るものと理解しているのですが、そん
>な単純なものではないのでしょうか。
僕も同じように理解しております。
コマンドアナライザなどのソフトを使って、ドライバからでるコマンドを
みても、最大値は256Sectorだったと記憶しております。
SATA/NVMeならソフトコマンドアナライザなら手元にチェックできる環境が
あるので、時間があるときにコマンドをみてみたいと思います。
おかしな挙動をするメーカーツールとかたまにあるので、変なときは、こ
れでコマンドをチェックしてみたりしてます（笑）
>▼marosamaさん：
>ストライピングサイズの関係があるのかもしれませんが、128KiB x8 で考
>えると 1MiB で十分な気もします。
>この理由何か考えられそうなことあるでしょうか。
ストライピングサイズとの関係はあるのではないかと思います。
僕の記憶ですと、2台でRAID0を構築した場合で、現在のSSDならストライピ
ングサイズ32KB以上がよかったと記憶ししています。
16KBとかに設定すると、128KiB QD32 T1のリード速度が32KB/64KBのときと
比較して、2割ほど遅くなりました。
そのときの128KiB QD32 T1と4KBのリード/ライトの速度は、誤差範囲の違い
でしかありませんでした。
128KiB QD32 T1でリード/ライトが最大になるようにストライビングサイズ
を調整して、ベンチを行うともしかしたら、2MiBなどのブロックサイズでも
変化がなくなるとかあるような気がします。
>アプリから 2MiB ブロックでコマンドを送れば、ドライバで 128KiB x 16
>に分解してドライブにコマンドを送るものと理解しているのですが、そん
>な単純なものではないのでしょうか。
僕も同じように理解しております。
コマンドアナライザなどのソフトを使って、ドライバからでるコマンドを
みても、最大値は256Sectorだったと記憶しております。
SATA/NVMeならソフトコマンドアナライザなら手元にチェックできる環境が
あるので、時間があるときにコマンドをみてみたいと思います。
おかしな挙動をするメーカーツールとかたまにあるので、変なときは、こ
れでコマンドをチェックしてみたりしてます（笑）
|
hiyohiyo
- 17/12/13(水) 0:53 -
|
▼marosamaさん：
>>アプリから 2MiB ブロックでコマンドを送れば、ドライバで 128KiB x 16
>>に分解してドライブにコマンドを送るものと理解しているのですが、そん
>>な単純なものではないのでしょうか。
>
>僕も同じように理解しております。
>コマンドアナライザなどのソフトを使って、ドライバからでるコマンドを
>みても、最大値は256Sectorだったと記憶しております。
>SATA/NVMeならソフトコマンドアナライザなら手元にチェックできる環境が
>あるので、時間があるときにコマンドをみてみたいと思います。
>おかしな挙動をするメーカーツールとかたまにあるので、変なときは、こ
>れでコマンドをチェックしてみたりしてます（笑）
何から何までありがとうございます。
なんというか、やっぱりプロは凄いですね。
NVMe 対応のソフトコマンドアナライザも出ているのですね。差し支えなければ教えていただけないでしょうか。
>>アプリから 2MiB ブロックでコマンドを送れば、ドライバで 128KiB x 16
>>に分解してドライブにコマンドを送るものと理解しているのですが、そん
>>な単純なものではないのでしょうか。
>
>僕も同じように理解しております。
>コマンドアナライザなどのソフトを使って、ドライバからでるコマンドを
>みても、最大値は256Sectorだったと記憶しております。
>SATA/NVMeならソフトコマンドアナライザなら手元にチェックできる環境が
>あるので、時間があるときにコマンドをみてみたいと思います。
>おかしな挙動をするメーカーツールとかたまにあるので、変なときは、こ
>れでコマンドをチェックしてみたりしてます（笑）
何から何までありがとうございます。
なんというか、やっぱりプロは凄いですね。
NVMe 対応のソフトコマンドアナライザも出ているのですね。差し支えなければ教えていただけないでしょうか。
|
marosama - 17/12/13(水) 7:52 - |
▼hiyohiyoさん：
>何から何までありがとうございます。
>なんというか、やっぱりプロは凄いですね。
僕は、中の人ではないので、全然すごくはないです。
仕事柄、SSDを触る機会は多いですけど。
>NVMe 対応のソフトコマンドアナライザも出ているのですね。差し支えな
>ければ教えていただけないでしょうか。
昔からあって有名なのは、busTRACEではないでしょうか。
最新バージョンならSATA/SAS/USB/ATAPI、PATA、SCSI、NVMeに対応して
います。ここを超えると、ハードウェアのバスアナライザになるので、
価格が20倍ぐらいに跳ね上がります。
Windows8以降セキュリティが年々強化されていて、RAWでは出せないコマ
ンド（Trim、SecureEraseなど、FirmUp用のコマンドとかもでなくなった
かも）が増えてきているので、RAWでコマンドを出したいときは制限が少
ないWindows 7で使った方が良いかもです。
>何から何までありがとうございます。
>なんというか、やっぱりプロは凄いですね。
僕は、中の人ではないので、全然すごくはないです。
仕事柄、SSDを触る機会は多いですけど。
>NVMe 対応のソフトコマンドアナライザも出ているのですね。差し支えな
>ければ教えていただけないでしょうか。
昔からあって有名なのは、busTRACEではないでしょうか。
最新バージョンならSATA/SAS/USB/ATAPI、PATA、SCSI、NVMeに対応して
います。ここを超えると、ハードウェアのバスアナライザになるので、
価格が20倍ぐらいに跳ね上がります。
Windows8以降セキュリティが年々強化されていて、RAWでは出せないコマ
ンド（Trim、SecureEraseなど、FirmUp用のコマンドとかもでなくなった
かも）が増えてきているので、RAWでコマンドを出したいときは制限が少
ないWindows 7で使った方が良いかもです。
|
hiyohiyo
- 17/12/14(木) 1:22 -
|
▼marosamaさん：
>▼hiyohiyoさん：
>
>>何から何までありがとうございます。
>>なんというか、やっぱりプロは凄いですね。
>
>僕は、中の人ではないので、全然すごくはないです。
>仕事柄、SSDを触る機会は多いですけど。
非常にお詳しいので SSD 業界の方なのかと思っていました。
>>NVMe 対応のソフトコマンドアナライザも出ているのですね。差し支えな
>>ければ教えていただけないでしょうか。
>
>昔からあって有名なのは、busTRACEではないでしょうか。
>最新バージョンならSATA/SAS/USB/ATAPI、PATA、SCSI、NVMeに対応して
>います。ここを超えると、ハードウェアのバスアナライザになるので、
>価格が20倍ぐらいに跳ね上がります。
情報ありがとうございます。個人ではハードウェアのバスアナライザはちょっと手が出ませんね・・・。
busTRACE 799ドルとはなかなかのお値段ですが、機能は凄そうです。
>▼hiyohiyoさん：
>
>>何から何までありがとうございます。
>>なんというか、やっぱりプロは凄いですね。
>
>僕は、中の人ではないので、全然すごくはないです。
>仕事柄、SSDを触る機会は多いですけど。
非常にお詳しいので SSD 業界の方なのかと思っていました。
>>NVMe 対応のソフトコマンドアナライザも出ているのですね。差し支えな
>>ければ教えていただけないでしょうか。
>
>昔からあって有名なのは、busTRACEではないでしょうか。
>最新バージョンならSATA/SAS/USB/ATAPI、PATA、SCSI、NVMeに対応して
>います。ここを超えると、ハードウェアのバスアナライザになるので、
>価格が20倍ぐらいに跳ね上がります。
情報ありがとうございます。個人ではハードウェアのバスアナライザはちょっと手が出ませんね・・・。
busTRACE 799ドルとはなかなかのお値段ですが、機能は凄そうです。