Jump to content











Photo
- - - - -

Ramdisk benchmark vs real world speeds...


  • Please log in to reply
7 replies to this topic

#1 vikan

vikan
  • Members
  • 4 posts
  •  
    United States

Posted 12 November 2016 - 10:02 PM

First of all, thanks to the creators/contributors of the awesome software. 

 

I build a new system and got plenty of ram on it. So, started looking at Ramdisk to see if I can speed up some programs.

 

I am using,

ImDisk version 2.0.9

Windows 10

32GB ramdisk  - NTFS,  64kb cluster size. 

 

I ran CrystalDiskMark on it and got pretty good speeds,

Rd  -   Seq: 5098  , Seq Q32: 4927 , 4K:819  , 4K Q32: 1025

Wr -    Seq: 8291  . Seq Q32: 9129 , 4K:600  , 4K Q32:  935

 

 

I then tried a simple copy speed tests,

1. ssd -> ramdisk 

2. ramdisk -> same ramdisk

3. one ramdisk  -> second ramdisk 

 

The max speed, according to windows, i got in any of the copy test was 1.2GB/s 

I am getting almost the low end of the benchmark numbers.

 

Is this in line with expectations? I am wondering if I did not set it up right.  Any suggestions?

 

Thanks



#2 v77

v77

    Silver Member

  • Team Reboot
  • 520 posts
  •  
    France

Posted 12 November 2016 - 10:52 PM

A copy requires both reads and writes, so you can already halve the mean of the values of the benchmark.

But that's not all. CrystalDiskMark likely uses unbuffered I/O, while Explorer uses buffered I/O in order to build the file cache. This speeds up things for slow devices such as hard drives, but this requires additional copies in RAM, which are enough to slow down this kind of benchmark.

So yes, there is nothing wrong with these results.



#3 vikan

vikan
  • Members
  • 4 posts
  •  
    United States

Posted 12 November 2016 - 11:04 PM

Thanks for the reply. 

 

Is there a way to make explorer , or any other process, treat IOs to the ramdisk as unbuffered?



#4 v77

v77

    Silver Member

  • Team Reboot
  • 520 posts
  •  
    France

Posted 13 November 2016 - 12:05 AM

I don't think so. If it is a software you are writing, you can simply open the files with FILE_FLAG_NO_BUFFERING, otherwise, unless an explicit support of the software, this is not possible.
But even so, accessing the cache is still faster for the file system because this doesn't require requests to the volume driver (that is, imdisk), so even for a ramdisk, for real life applications, this would just make things slower.



#5 vikan

vikan
  • Members
  • 4 posts
  •  
    United States

Posted 13 November 2016 - 02:25 PM

Is there is a way to increase the buffer cache size to 32GB in windows.  I can then completely forgo ramdisk. 


Edited by vikan, 13 November 2016 - 02:25 PM.


#6 v77

v77

    Silver Member

  • Team Reboot
  • 520 posts
  •  
    France

Posted 13 November 2016 - 03:07 PM

The size of the cache is as large as possible. As long as there is enough RAM, Windows tries to keep the files in cache. I know no way (and no advantage) to limit the amount of cache.
It is possible to invalidate the cache though, which can be useful for testing performances of file access.
But if your only goal is to maximize performances, a ramdisk is useful only in the case you want to be sure to have always a fast access to some files, and you are sure to use them (to avoid loading them for nothing).

Nowadays, the interests of a ramdisk are often elsewhere:
- privacy
- lifespan of SSDs
- space to decompress files quickly
- auto-cleaned temporary folders



#7 vikan

vikan
  • Members
  • 4 posts
  •  
    United States

Posted 13 November 2016 - 05:24 PM

Appreciate your responses. 

 

More questions, for clarification,

If a program is writing to , or creating a file, windows writes it to ram  and reports it done without waiting for the actual write to the disk is completed, unless the process requests unbuffered-writes? And the size of the file  , or how many files, it can do that for at any given time depends only on the ram available? 



#8 v77

v77

    Silver Member

  • Team Reboot
  • 520 posts
  •  
    France

Posted 13 November 2016 - 06:27 PM

Yes, it's the "delayed write".
But in fact, a process can use the cache and still disable the delayed write (FILE_FLAG_WRITE_THROUGH).






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users