26

I want to test integrity and global performances of no-ECC memory chips on a custom board

Are there some tools that run under linux so I can monitor system and global temperature in the same time ?

Are there some no-ECC specific tests to do in general ?

EDIT 1:

I already know how to monitor temperature (I use a special platform feature /sys/devices/platform/......../temp1_input).

For now :

  • wazoox : it works but I've to code my own tests
  • Jason Huntley :
    • ramspeed : does not work on arm
    • stream benchmark : it works and is very fast, so I'll look if it's accurate and complete
    • memtest : I'll try later, since it does not run directly from linux
    • stress for fedora : I'll try later too, it's too problematic for me to install fedora now

I found this distribution : http://www.stresslinux.org/sl/

I'll continue to check tools that run directly under linux without too big dependencies, after I'll maybe give a try to solutions like stresslinux, memtest, stress for fedora.

Thanks for you answers, I'll continue to investigate

moul
  • 545
  • 1
  • 4
  • 11
  • It would help if you provide us the linux distribution you're working with. Are you running a server or desktop distribution? Does it include XServer? – Jason Huntley Mar 21 '12 at 15:56
  • I use linux 3.0 bare metal with busybox, rootfs is on nfs, so I compile tools from another host with an arm cross compiler. There is no XServer. – moul Mar 21 '12 at 16:55

4 Answers4

16

Here's the way I sometimes test ram: first mount two tmpfs (by default tmpfs is half the ram):

# mount -t tmpfs /mnt/test1 /mnt/test1
# mount -t tmpfs /mnt/test2 /mnt/test2

Check free memory and free space:

# free
             total       used       free     shared    buffers     cached
Mem:        252076     234760      17316          0      75856      62328
-/+ buffers/cache:      96576     155500
Swap:      1048820        332    1048488

# df -h -t tmpfs
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
tmpfs                 124M     0  124M   0% /lib/init/rw
udev                   10M  104K  9,9M   2% /dev
tmpfs                 124M     0  124M   0% /dev/shm
/mnt/test1            124M     0  124M   0% /mnt/test1
/mnt/test2            124M     0  124M   0% /mnt/test2

Now fill the tmpfs with dd:

# dd if=/dev/zero of=/mnt/test1/test bs=1M 
dd: écriture de `/mnt/test1/test': Aucun espace disponible sur le périphérique
123+0 enregistrements lus
122+0 enregistrements écrits
128802816 octets (129 MB) copiés, 1,81943 seconde, 70,8 MB/s

# dd if=/dev/zero of=/mnt/test2/test bs=1M 
dd: écriture de `/mnt/test2/test': Aucun espace disponible sur le périphérique
123+0 enregistrements lus
122+0 enregistrements écrits
128802816 octets (129 MB) copiés, 5,78563 seconde, 22,3 MB/s

You can check that your memory is actually quite full:

# free
             total       used       free     shared    buffers     cached
Mem:        252076     248824       3252          0       1156     226380
-/+ buffers/cache:      21288     230788
Swap:      1048820      50020     998800

Now you may run various tests, for instance check that both temp files are identical, directly or running md5sum, sha1sum, etc:

# time cmp /mnt/test1/test /mnt/test2/test 

real    0m4.328s
user    0m0.041s
sys     0m1.117s

About temperature monitoring, I know only of lm-sensors. I don't know if it manages your particular hardware, but you probably could give it a try anyway.

wazoox
  • 6,782
  • 4
  • 30
  • 62
  • 5
    This benchmark will be affected by CPU cache, but it is a good idea. – Mircea Vutcovici Mar 21 '12 at 18:04
  • 2
    Didn't test myself, but Mircea is probably right: so i would "echo 3 > /proc/sys/vm/drop_caches" to free pagecaches, dentries and inodes, that should do it. – Manuel Sep 11 '13 at 13:12
  • 1
    Those are file system caches, not CPU caches. – Mircea Vutcovici Feb 18 '14 at 21:03
  • 1
    +1 This `dd` method (on an old AMD Athlon 64 3200+) has given me results consistently proportional to changes in memory clock speed, which I take to mean that it is good enough. Not sure, though, why you would want to clog the entire system memory with `/dev/zero` - my system froze when I attempted to do that. – Lumi Feb 28 '14 at 18:53
  • 3
    I have adapted this in a simple bash script that I use to benchmark VPS providers - https://bitbucket.org/snippets/danielsokolowski/G5oeA – Daniel Sokolowski Dec 05 '16 at 16:59
  • oh cool @DanielSokolowski ill ty to contact im @ g mail.com – Kangarooo Jul 07 '17 at 01:45
  • @Lumi I fill in the RAM to test it (that's why I ran cmp, md5sum, etc afterwards), it's a poor man's Memtest86+ :) If it crashes your system, either you have no swap, or your RAM may be faulty. – wazoox Apr 07 '22 at 15:00
8

What are the best possible ways to benchmark RAM (no-ECC) under linux / arm?

RamSpeed is the only multiplatform memory benchmark tool I'm aware of. You might be able to compile it for arm, if supported:

https://github.com/cruvolo/ramspeed-smp

If it's not supported, you might be able to benchmark using stream:

https://web.archive.org/web/20211104122453/http://www.cs.virginia.edu/stream/

want to test integrity and global performances of no-ECC memory chips on a custom board

Here, I've used memtest on many occasions for integrity checking and it works great:

http://www.memtest.org/

*Note, I've only read this supports Arm. However, I haven't tested on an Arm.

Are there some tools that run under linux so I can monitor system and global temperature in the same time ?

If the distribution you're using supports yum, you can easily install lm_sensors:

yum install lm_sensors

You can also download and compile from: here http://www.lm-sensors.org/

However, I'm not certain it will provide temperature data regarding your memory. Your motherboard also has to have sensors for reading mem temperature.

Are there some no-ECC specific tests to do in general ?

memtest does include tests for both ECC and non-ECC

I just remembered one last thing you could try. Get fedora for arm architecture or the rpm. You can run the stress package which will stress test your cpu and memory:

stress-1.0.4-4.fc13.armv5tel.rpm

If busybox has an rpm installer packaged with it, you might be able to deploy one of the arm rpms from the fedora distribution.

Paul
  • 2,755
  • 6
  • 24
  • 35
Jason Huntley
  • 1,253
  • 3
  • 10
  • 22
1

Write a file into an existing tmpfs like /tmp with dd as wazoox suggested, but limit its size to less then half of your free memory.

First, find out how much memory is available:

> free -h                                                                       
              total        used        free      shared  buff/cache  available 
Mem:            15G        3.0G         11G        540M        1.0G         11G 
Swap:            9G        1.2M          9G

Then, write a file, in this case 4GB in total using 4000 blocks of 1MB:

> dd if=/dev/zero of=/tmp/testfile bs=1M count=4000 
4000+0 records in
4000+0 records out
4194304000 bytes (4.2 GB, 3.9 GiB) copied, 1.1395 s, 3.7 GB/s

This way you will avoid swapping and there is no need to mount anything.

baldrianbandit
  • 36
  • 1
  • Something seems to be artificially limiting the speed of `tmpfs` on my RHEL6/7 machines. I get the same 4GB/s as you whether I run this command on quad channel DDR3-1866 machine, a quad channel DDR4-2666 machine, or that same machine with only two memory channels populated. These should be writing to memory at 60, 85 and 42GB/s respectivly, not 4GB/s. – Mark Booth Jul 03 '18 at 14:00
  • Might be dd is just doing loops with a constant waiting intervall and thus, limiting the speed of the whole action. Try it the other way around: dd if=/dev/zero of=/tmp/testfile bs=4000M count=1 – baldrianbandit Jul 05 '18 at 08:53
  • It's very odd, I've tried with a variety of `bs` and `count`s and the best combination was with `bs=512K` but it never goes above 4.2GB/s on a machine which gives 43GB/s with the STREAM benchmark. – Mark Booth Jul 05 '18 at 10:54
0

I used u-boot's memtest, there are two tests (see u-boot/common/cmd_mem.c):

The first test is simple (write,check), the second test is activated by #define CONFIG_SYS_ALT_MEMTEST 1 and add more tests,

take care of passing a start offset (argv[1]) after the u-boot memory space, i.e mtest 0x200000.

moul
  • 545
  • 1
  • 4
  • 11