Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
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

3 Answers 3

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.

share|improve this answer
2  
This benchmark will be affected by CPU cache, but it is a good idea. –  Mircea Vutcovici Mar 21 '12 at 18:04
1  
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
    
Those are file system caches, not CPU caches. –  Mircea Vutcovici Feb 18 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 at 18:53

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:

http://alasir.com/software/ramspeed/

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

http://www.cs.virginia.edu/stream/ref.html

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 mmemory. 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.