Joined
·
436 Posts
Speaking of virtual memory performance, my wish is to collect useful statistics on IOPS random 4KiB read/write/read-write.
The scenario that interests me is the actual performance of modern SSDs when the application (single-threaded) starts bombarding the drive with small packets like 128B/4KiB ... across 48GB big and more pool ('Test Size' in CrystalDiskMark terminology). Seeing how Samsung 860 PRO boasts:
CACHE MEMORY
512 MB Low Power DDR4 (256 GB, 512 GB)
1 GB Low Power DDR4 (1,024 GB)
2 GB Low Power DDR4 (2,048 GB)
4 GB Low Power DDR4 (4,096 GB)
RANDOM READ (4KB, QD1)
Up to 11,000 IOPS
RANDOM WRITE (4KB, QD1)
Up to 43,000 IOPS
Since the Japanese author didn't report the IOPS, manually I have to divide 4KiBQ1T1 score by 4KiB.
It prompts for using much bigger 'Test Size' than the default 1GiB, otherwise stressing the cache mainly, which is also useful.
These days I intend to buy the 256GB model and put it to the test, at the moment I can only test my latest SSD - the cheapest Kingston - A400 2.5" 240GB SATA III TLC:
#1 Screenshot: 1GiB
So, the (5.411*1000*1000)/(4*1024)= 1,321 IOPS (random reads within 1GiB)
#2 Screenshot: 16GiB
So, the (5.465*1000*1000)/(4*1024)= 1,334 IOPS (random reads within 16GiB)
#3 Screenshot: 32GiB
So, the (5.307*1000*1000)/(4*1024)= 1,295 IOPS (random reads within 32GiB)
Notice the inconsistency, how write performance is halved and restored.
By the way, currently I am into writing my own (not using the OS virtual memory allocator) I/O code bypassing the malloc(). All small blocks/pools are to be handled by single fread()/fwrite().
Naturally, the I/O intensive bombardment across 48+GB pool with ~128B long chunks requires much more than 10,000 IOPS, OPTANE is promising, but I want to dig into regular SSDs first.
Incoming results for ...
In the meantime, you are welcome to share screenshots of your own.
The scenario that interests me is the actual performance of modern SSDs when the application (single-threaded) starts bombarding the drive with small packets like 128B/4KiB ... across 48GB big and more pool ('Test Size' in CrystalDiskMark terminology). Seeing how Samsung 860 PRO boasts:
CACHE MEMORY
512 MB Low Power DDR4 (256 GB, 512 GB)
1 GB Low Power DDR4 (1,024 GB)
2 GB Low Power DDR4 (2,048 GB)
4 GB Low Power DDR4 (4,096 GB)
RANDOM READ (4KB, QD1)
Up to 11,000 IOPS
RANDOM WRITE (4KB, QD1)
Up to 43,000 IOPS
Since the Japanese author didn't report the IOPS, manually I have to divide 4KiBQ1T1 score by 4KiB.
It prompts for using much bigger 'Test Size' than the default 1GiB, otherwise stressing the cache mainly, which is also useful.
These days I intend to buy the 256GB model and put it to the test, at the moment I can only test my latest SSD - the cheapest Kingston - A400 2.5" 240GB SATA III TLC:

#1 Screenshot: 1GiB
So, the (5.411*1000*1000)/(4*1024)= 1,321 IOPS (random reads within 1GiB)
#2 Screenshot: 16GiB
So, the (5.465*1000*1000)/(4*1024)= 1,334 IOPS (random reads within 16GiB)
#3 Screenshot: 32GiB
So, the (5.307*1000*1000)/(4*1024)= 1,295 IOPS (random reads within 32GiB)
Notice the inconsistency, how write performance is halved and restored.
By the way, currently I am into writing my own (not using the OS virtual memory allocator) I/O code bypassing the malloc(). All small blocks/pools are to be handled by single fread()/fwrite().
Naturally, the I/O intensive bombardment across 48+GB pool with ~128B long chunks requires much more than 10,000 IOPS, OPTANE is promising, but I want to dig into regular SSDs first.
Incoming results for ...

In the meantime, you are welcome to share screenshots of your own.
Attachments
-
3.1 MB Views: 309
-
2.3 MB Views: 314
-
2.3 MB Views: 311