Re: Could RAM possibly be just 3-4 times faster than bare hdd writes and reads? or, is the Linux kernel doing its 'magic' in the bg? or, ...
On Wed, Jun 17, 2020 at 12:14:55PM +0200, Albretch Mueller wrote:
HDDs have their internal caching mechanism and I have heard that the
Linux kernel uses RAM very effitiently, but to my understanding RAM
being only 3-4 times faster doesn't make much sense, so I may be doing
or understanding something not entirely right.
Basically, yeah. Your "disk" numbers are unrealistically high. Your test
dataset is too small and you aren't flushing the cache before exiting
dd, so you are largely seeing the time it takes to write to cache, not
to disk.
(adding the times is just making this harder to read)
# time dd if=/dev/zero of="${_RAM_MNT}"/zero bs=4k count=100000
409600000 Bytes (410 MB, 391 MiB) kopiert, 0,756943 s, 541 MB/s
# time dd if="${_RAM_MNT}"/zero of=/dev/null bs=4k count=100000
409600000 Bytes (410 MB, 391 MiB) kopiert, 0,36381 s, 1,1 GB/s
$ time dd if=/dev/zero of="${_HDD_DIR}"/zero bs=4k count=100000
409600000 Bytes (410 MB, 391 MiB) kopiert, 1,92086 s, 213 MB/s
$ time dd if="${_HDD_DIR}"/zero of=/dev/null bs=4k count=100000
409600000 Bytes (410 MB, 391 MiB) kopiert, 0,521688 s, 785 MB/s
Try adding conv=fdatasync to your dd command line, that causes dd to
wait until the cache has actually flushed to disk before reporting &
exiting. For the read tests, you need to either drop all the system
cache or simply use test files that are larger than the system memory.
As others have mentioned, even your RAM times are slow, is this possibly
a low power CPU? The 4k bs is also going to limit performance, try at
least 64k and maybe 1M for this application. If the CPU (or RAM) isn't
the bottleneck, after those changes I'd expect hard disk speeds to be
more on the order of 100MByte/s and ram disk speeds more on the order of
a few GByte/s.
Reply to: