Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an alix board on which I have installed debian4alix (sqeeze). After using it for a while I noticed that the write performance of the board was pretty low.

I ran the following test:

dd count=100 bs=1M if=/dev/urandom of=/var/www/cgrid/test

This yielded the following:

100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 328.903 s, 319 kB/s

This is the same speed I get when running the test on the compact flash card that the OS is installed on or on a flash disk. I had tested the flash disk performance on a linux desktop PC and achieved speeds around 15.3 MB/s using the same tests.

My read speed on the alix board is around 9MB/s (tested with hdparm -t)

I would like to know if the slow write speeds I am receiving is a result of the operating system ( since it is not running directly off the compact flash card but off a ramdisk) or from the embedded hardware solution being really slow.

share|improve this question
    
Wtf... Give me my board back! –  Alix Axel Oct 4 '13 at 22:47
add comment

1 Answer

up vote 1 down vote accepted

I am quite certain the board is slower then desktop in terms hardware. But urandom make it worse.

The board is using a 500MHz CPU vs 2-3GHz desktop CPU. With if=/dev/urandom, your test is more about how fast the system can handle urandom. You are comparing CPU performance, not I/O.

Additionally, if the board only have 256M of ram, the OS may start swapping when creating 100M ram disk file. If that happen, it will have a big hit on test result. Maybe test with 50M file.

Use if=/dev/zero

Don't use if=/dev/urandom. It is a very costly call for this test. Instead use if=/dev/zero.

Test 1 - Write 100M to disk

Following is my test result from a virtual machine, also writing 100M.

if=/dev/zero

john@U64D211:~$ time dd count=100 bs=1M if=/dev/zero of=test
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.493612 s, 212 MB/s

real    0m0.540s
user    0m0.020s
sys 0m0.516s

if=/dev/urandom

john@U64D211:~$ rm test
john@U64D211:~$ time dd count=100 bs=1M if=/dev/urandom of=test
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 10.8723 s, 9.6 MB/s

real    0m10.909s
user    0m0.004s
sys 0m10.893s
john@U64D211:~$ 

Test 2 - Write 100M to /dev/null

To show how costly is urandom, lets write to /dev/null, so no writing to disk.

if=/dev/zero

john@U64D211:~$ time dd count=100 bs=1M if=/dev/zero of=/dev/null
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0240906 s, 4.4 GB/s

real    0m0.061s
user    0m0.012s
sys 0m0.052s

if=/dev/urandom

john@U64D211:~$ time dd count=100 bs=1M if=/dev/urandom of=/dev/null
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 10.4979 s, 10.0 MB/s

real    0m10.555s
user    0m0.024s
sys 0m10.513s

So when writing to /dev/null, almost 99% of time is spent by urandom system call.

PS1: VM has 4G of ram.

PS2: File caching do/may have affect the test result to some extend, but the difference between the if option is so huge that it is safe to ignore caching factor. And the effect should apply to both cases anyway.

PS3: I did not average out the test results. But I did run each multiple times with very similar result.

share|improve this answer
    
Thanks. You are correct, I got feedback from the maintainer of the OS who basically did the same thing as you. I didn't realize that a call to urandom was so expensive. –  tensai Jan 6 '13 at 11:23
    
Out of curiosity, what is the result with if=/dev/zero? –  John Siu Jan 11 '13 at 19:51
    
I tested it by writing to the actual file system instead of /dev/null time dd count=100 bs=1M if=/dev/zero of=/test 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 5.61246 s, 18.7 MB/s real 0m5.620s user 0m0.008s sys 0m1.740s –  tensai Jan 15 '13 at 17:08
add comment

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.