CrystalDiskInfoやCrystalDiskMarkなどCrystal Dew World製品に関する総合掲示板です。
 |
 |
CrystalDiskMark 4 要望、実行結果募集中 hiyohiyo 15/3/8(日) 23:44 |
![[添付]](./brd/myk/image/clip_icon.gif){kind=icon}
|
|
|
Re:Dev4のバグ、と要望です marosama 15/3/19(木) 1:53 |
|
 |
Re:Dev4のバグ、と要望です 金華山の仙人 15/3/19(木) 2:28 |
|
 |
Re:Dev4のバグ、と要望です hiyohiyo 15/3/24(火) 23:21 |
|
|
Re:Dev4のバグ、と要望です hiyohiyo 15/3/27(金) 14:56 |
|
marosama - 15/3/19(木) 1:53 - |
▼UKさん：
>■コピーの不具合
>Dev4でコピーした時にSequential Read Q1 T1のスコアがQ32/T1のものとおなじになってしまうようです。（★の部分）
> Sequential Read (Q= 1,T= 1) : 547.157 MB/s ★
> Sequential Write (Q= 1,T= 1) : 511.283 MB/s ★
開発者でもない僕が答えるようなことではないかもしれませんが、
これは、バグではなく仕様だと思います。
Windowsというか、大抵のOSの場合、ドライバーの制限によって、
実際のコマンドあたりの最大転送サイズが、256セクタ（1セクタ
ー512バイトの場合で128KB）に制限されています。
USB3の場合のみ製品によって、1024セクタ（512KB）が使用でき
ます。
このため、転送サイズをソフト側で1MBと設定しても、実際にド
ライブに送られるライトまたはリードコマンドは、128KB単位に
分割され、8回送られます。
CDMの挙動を見る限りでは、転送サイズを1MBに設定しても、実際
には、転送サイズ128KBのQD=8状態で計測されていると推測されます。
IOMeterやTxBENCHでチェックされるとわかると思いますが、転送サイ
ズ128KBで計測する場合、QD=4ぐらいでSATA6G接続のSSDなら、ほぼ最
大速度を計測できます（シーケンシャルリード/ライトに限る）。
ということで、シーケンシャルに限定していうと、CDMで転送サイズに
1MBを設定した段階で、QD1だろうかQD32だろうがすでに最大速度に達し
ているので、同じ結果になってある意味当然だと思います。
なお、僕が試した限りでは、NVMe（ドライバーはMS謹製）でも、最大
転送サイズは、256セクタに制限されておりました。
NVMeの場合、QDをより深くしたり、スレッド数を増やすことで、リー
ド/ライト性能が向上すると推測されます。
>■コピーの不具合
>Dev4でコピーした時にSequential Read Q1 T1のスコアがQ32/T1のものとおなじになってしまうようです。（★の部分）
> Sequential Read (Q= 1,T= 1) : 547.157 MB/s ★
> Sequential Write (Q= 1,T= 1) : 511.283 MB/s ★
開発者でもない僕が答えるようなことではないかもしれませんが、
これは、バグではなく仕様だと思います。
Windowsというか、大抵のOSの場合、ドライバーの制限によって、
実際のコマンドあたりの最大転送サイズが、256セクタ（1セクタ
ー512バイトの場合で128KB）に制限されています。
USB3の場合のみ製品によって、1024セクタ（512KB）が使用でき
ます。
このため、転送サイズをソフト側で1MBと設定しても、実際にド
ライブに送られるライトまたはリードコマンドは、128KB単位に
分割され、8回送られます。
CDMの挙動を見る限りでは、転送サイズを1MBに設定しても、実際
には、転送サイズ128KBのQD=8状態で計測されていると推測されます。
IOMeterやTxBENCHでチェックされるとわかると思いますが、転送サイ
ズ128KBで計測する場合、QD=4ぐらいでSATA6G接続のSSDなら、ほぼ最
大速度を計測できます（シーケンシャルリード/ライトに限る）。
ということで、シーケンシャルに限定していうと、CDMで転送サイズに
1MBを設定した段階で、QD1だろうかQD32だろうがすでに最大速度に達し
ているので、同じ結果になってある意味当然だと思います。
なお、僕が試した限りでは、NVMe（ドライバーはMS謹製）でも、最大
転送サイズは、256セクタに制限されておりました。
NVMeの場合、QDをより深くしたり、スレッド数を増やすことで、リー
ド/ライト性能が向上すると推測されます。
|
金華山の仙人 - 15/3/19(木) 2:28 - |
▼marosamaさん：
残念ながら、画像dataと違う結果がテキストdataに出てる時点で、バグですね。
残念ながら、画像dataと違う結果がテキストdataに出てる時点で、バグですね。
|
hiyohiyo
- 15/3/24(火) 23:21 -
|
▼marosamaさん：
>▼UKさん：
>>■コピーの不具合
>>Dev4でコピーした時にSequential Read Q1 T1のスコアがQ32/T1のものとおなじになってしまうようです。（★の部分）
>> Sequential Read (Q= 1,T= 1) : 547.157 MB/s ★
>> Sequential Write (Q= 1,T= 1) : 511.283 MB/s ★
>
>開発者でもない僕が答えるようなことではないかもしれませんが、
>これは、バグではなく仕様だと思います。
すみません。恥ずかしながらネタの参照元がバグってました。Dev5 で修正しました。
>Windowsというか、大抵のOSの場合、ドライバーの制限によって、
>実際のコマンドあたりの最大転送サイズが、256セクタ（1セクタ
>ー512バイトの場合で128KB）に制限されています。
>USB3の場合のみ製品によって、1024セクタ（512KB）が使用でき
>ます。
>
>このため、転送サイズをソフト側で1MBと設定しても、実際にド
>ライブに送られるライトまたはリードコマンドは、128KB単位に
>分割され、8回送られます。
>CDMの挙動を見る限りでは、転送サイズを1MBに設定しても、実際
>には、転送サイズ128KBのQD=8状態で計測されていると推測されます。
>
>IOMeterやTxBENCHでチェックされるとわかると思いますが、転送サイ
>ズ128KBで計測する場合、QD=4ぐらいでSATA6G接続のSSDなら、ほぼ最
>大速度を計測できます（シーケンシャルリード/ライトに限る）。
>
>ということで、シーケンシャルに限定していうと、CDMで転送サイズに
>1MBを設定した段階で、QD1だろうかQD32だろうがすでに最大速度に達し
>ているので、同じ結果になってある意味当然だと思います。
>
>なお、僕が試した限りでは、NVMe（ドライバーはMS謹製）でも、最大
>転送サイズは、256セクタに制限されておりました。
>NVMeの場合、QDをより深くしたり、スレッド数を増やすことで、リー
>ド/ライト性能が向上すると推測されます。
技術的な考察ありがとうございます。
ソフトウェア側で 1MiB ブロックを利用していても内部では 128KiB x 8 に分割されるというのはごもっともですね。
通常のシーケンシャルテストについて、QD=1 表記は技術的に不適切ですね。
また、Multi Threads/Queues なシーケンシャルテストについては 128KiB 化にするべきですね。
大きな仕様変更となりますので関連調査をした上で、Dev6 以降で対応します。
準備が出来次第ソースコードも公開しますので、お気づきの点がありましたら技術的なアドバイスをいただけると幸いです。
>▼UKさん：
>>■コピーの不具合
>>Dev4でコピーした時にSequential Read Q1 T1のスコアがQ32/T1のものとおなじになってしまうようです。（★の部分）
>> Sequential Read (Q= 1,T= 1) : 547.157 MB/s ★
>> Sequential Write (Q= 1,T= 1) : 511.283 MB/s ★
>
>開発者でもない僕が答えるようなことではないかもしれませんが、
>これは、バグではなく仕様だと思います。
すみません。恥ずかしながらネタの参照元がバグってました。Dev5 で修正しました。
>Windowsというか、大抵のOSの場合、ドライバーの制限によって、
>実際のコマンドあたりの最大転送サイズが、256セクタ（1セクタ
>ー512バイトの場合で128KB）に制限されています。
>USB3の場合のみ製品によって、1024セクタ（512KB）が使用でき
>ます。
>
>このため、転送サイズをソフト側で1MBと設定しても、実際にド
>ライブに送られるライトまたはリードコマンドは、128KB単位に
>分割され、8回送られます。
>CDMの挙動を見る限りでは、転送サイズを1MBに設定しても、実際
>には、転送サイズ128KBのQD=8状態で計測されていると推測されます。
>
>IOMeterやTxBENCHでチェックされるとわかると思いますが、転送サイ
>ズ128KBで計測する場合、QD=4ぐらいでSATA6G接続のSSDなら、ほぼ最
>大速度を計測できます（シーケンシャルリード/ライトに限る）。
>
>ということで、シーケンシャルに限定していうと、CDMで転送サイズに
>1MBを設定した段階で、QD1だろうかQD32だろうがすでに最大速度に達し
>ているので、同じ結果になってある意味当然だと思います。
>
>なお、僕が試した限りでは、NVMe（ドライバーはMS謹製）でも、最大
>転送サイズは、256セクタに制限されておりました。
>NVMeの場合、QDをより深くしたり、スレッド数を増やすことで、リー
>ド/ライト性能が向上すると推測されます。
技術的な考察ありがとうございます。
ソフトウェア側で 1MiB ブロックを利用していても内部では 128KiB x 8 に分割されるというのはごもっともですね。
通常のシーケンシャルテストについて、QD=1 表記は技術的に不適切ですね。
また、Multi Threads/Queues なシーケンシャルテストについては 128KiB 化にするべきですね。
大きな仕様変更となりますので関連調査をした上で、Dev6 以降で対応します。
準備が出来次第ソースコードも公開しますので、お気づきの点がありましたら技術的なアドバイスをいただけると幸いです。
|
hiyohiyo
- 15/3/27(金) 14:56 -
|
▼hiyohiyoさん：
>▼marosamaさん：
>通常のシーケンシャルテストについて、QD=1 表記は技術的に不適切ですね。
>また、Multi Threads/Queues なシーケンシャルテストについては 128KiB 化にするべきですね。
Dev6 で変更しました。
>▼marosamaさん：
>通常のシーケンシャルテストについて、QD=1 表記は技術的に不適切ですね。
>また、Multi Threads/Queues なシーケンシャルテストについては 128KiB 化にするべきですね。
Dev6 で変更しました。