Romex Software Forum

Hello, Everyone.
I have a problem with read/write speed.

My system is: Supermicro X9DRW-3TF+, 2x Xeon e5-2670, 24x 16GB (=384Gb), Windows Server 2016.
Ramdisk size is 350GB.

CrystallDiskMark speed test show low speed at test 2-4 (small block reading and writing).

Is it possible to increase the speed?

If you use SCSI ramdisk, you may try the DirectIO type which have better speed. However, some applications might not recognize DirectIO ramdisks.

There is a issue with the disk controller?
(It's probably a problem on the driver side, but it could also be a problem on the Windows or DiskSpd side.)

I ran the same test on crystal disk mark.
When I ran the same test with crystal disk mark, I found that the disk controller was multithreaded for SEQ1M and
SEQ1M was multi-threaded, while the others were single-threaded.

The disk controller was multi-threaded for SEQ1M and single-threaded for the rest.

Note that crystal disk mark is a front-end to Microsoft DiskSpd, so it is not possible to use
If you want to test it, it would be easier for Primo to use Microsoft DiskSpd for command line (batch) processing.

When the block size (buffer) is 1MiB, the processing is done in multi-threading based on the number of queues, but when the block size is 4KiB, the processing is done in single-threading regardless of the number of queues.

Since the number of queues is one read/write instruction (basically one user application), the actual experience is slow.
You can see this by trying to copy files in a RAM disk.

The default size of the program's file stream buffer is 4KiB (4,096B) units, so the block size is 4KiB, the same as DiskMark.

The smaller the block size, the slower it gets.



------------------------------------------------------------------------------
CrystalDiskMark 8.0.2 x64 (C) 2007-2021 hiyohiyo
Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
RND 512KiB (Q= 8, T= 1): 26611.427 MB/s [ 50757.3 IOPS] < 137.98 us>
RND 256KiB (Q= 8, T= 1): 26214.279 MB/s [ 99999.5 IOPS] < 69.83 us>
RND 128KiB (Q= 8, T= 1): 24495.692 MB/s [ 186887.3 IOPS] < 37.34 us>
RND 64KiB (Q= 8, T= 1): 16913.262 MB/s [ 258075.9 IOPS] < 27.03 us>
RND 32KiB (Q= 8, T= 1): 9540.226 MB/s [ 291144.6 IOPS] < 23.96 us>
RND 16KiB (Q= 8, T= 1): 4708.448 MB/s [ 287380.9 IOPS] < 24.26 us>
RND 8KiB (Q= 8, T= 1): 2536.260 MB/s [ 309602.1 IOPS] < 22.52 us>
RND 4KiB (Q= 8, T= 1): 1374.207 MB/s [ 335499.8 IOPS] < 20.78 us>

[Write]
RND 512KiB (Q= 8, T= 1): 31079.415 MB/s [ 59279.3 IOPS] < 119.10 us>
RND 256KiB (Q= 8, T= 1): 15279.514 MB/s [ 58286.7 IOPS] < 121.49 us>
RND 128KiB (Q= 8, T= 1): 14810.459 MB/s [ 112994.8 IOPS] < 61.78 us>
RND 64KiB (Q= 8, T= 1): 13596.951 MB/s [ 207473.0 IOPS] < 33.63 us>
RND 32KiB (Q= 8, T= 1): 7924.974 MB/s [ 241851.0 IOPS] < 28.85 us>
RND 16KiB (Q= 8, T= 1): 4057.642 MB/s [ 247658.8 IOPS] < 28.17 us>
RND 8KiB (Q= 8, T= 1): 2190.218 MB/s [ 267360.6 IOPS] < 26.10 us>
RND 4KiB (Q= 8, T= 1): 1144.666 MB/s [ 279459.5 IOPS] < 24.95 us>


Profile: Default
Test: 1 GiB (x5) [R: 1% (60/8191MiB)]
Mode: [Admin]
Time: Measure 5 sec / Interval 5 sec
Date: 2021/06/25 17:21:20
OS: Windows 10 Professional [10.0 Build 19043] (x64)

It takes certain additional time to process a read/write request each time. The smaller the block size, the higher the proportion of the process time to the pure read/write time. Multithreads will take more process time because Windows need to schedule threads. This cost is relative high compared with 4KB read/write time and might beyond the benefits gained from multithreads.

Sequential access tends to be faster than random access whatever the medium for different reasons (for hard discs, it's the time taken to move the head to a new track, for RAM the time taken to fire up the appropriate Row/Column Address Strobes).

In my experience, the difference between best/worst case performance can vary by a factor of 450 with hard discs, 15-20 with SSDs and 7-8 with ramdisks/PrimoCached volumes. In both Viktor11's and SysVR's cases (welcome to the forums, both of you!) the ratio appears to be greater than expected.

There may be other software interfering with disk access (e.g. an overly-aggressive virus/file scanner), so try using software like Process Explorer or Process Hacker to monitor CPU utilisation and disk I/O during a benchmark run, to check that no other processes are taking up significant CPU or I/O.

Primo Ramdisk is very reliant on memory performance so any issue with memory setup can have an effect (in Viktor11's case, NUMA settings may come into play). To check this try running a memory benchmark/test and checking BIOS settings.

CPU Usage.

SysVR,

Your CPU usage is far higher than I would expect (what CPU is your system using?) - my experience with CDM is that it would max out one core and make significant usage of two more (though the queuing part of the benchmark would be spread out over more cores). Check (using the utilities mentioned above) for other software using high CPU during the benchmark and try disabling or re-configuring them.

Microsoft Windows [Version 10.0.19043.1055]
[2021/06/01] CrystalDiskMark 8.0.2 ZIP Version.
ProcessHacker 2.39

By the way, the image of the CPU bar above is
thilmera7
system monitor.

"System" CPU is high, though that would be at least in part due to the ramdisk driver. Does it drop to near 0% when the benchmark ends, or does it remain quite high?

You seem to be running Windows Defender (msmpeng.exe) and Spy Stopper Pro (ssp.exe) for anti-malware. I don't know much about Spy Stopper but if your system CPU remains high and you can't identify the cause, it may be worth giving your system a check using one of the standalone scanners listed on this page.

oops.
SSP is a platform for a desktop mascot called "ukagaka".

The benchmark will drop to 0% when finished.
Primo Ramdisk Professional Edition 6.4.1 Trial.
CDM RND 512KiB (Q= 8, T= 1)