Ah, but it isn't. 

Notice that I'm not using the disk. I'm using memory.

/dev/shm is memory.


I'm not sure about zero bits.
Normally I would say no... but you never know what optimization techniques might be employed under the hood.
Engineers are getting smarter all the time - think of how LCDs consumer less power when the screen has a colorful image than when it is all black pixels.


What brand of SD card are you using?

I think the KingMax brand is akin to the chinese MP4 players you see on ebay. It's not really class 10, it just says that. Just look at the price on amazon. It wouldn't be so cheap if it were a real class 10.

I have a Kingston class 10 on order. I'll update when I get that.



Another thing to factor in is that `dd` exists when the write finishes to the buffer, not disk.
This modification would fix that:

    #NOTE: This fills the cache buffers with data 
    cat /dev/shm/rand.dd /dev/shm/rand.dd | dd of=${MMC}/rand.dd

    # The overhead of the un`sync`d data above will make this more accurate
    cat /dev/shm/rand.dd /dev/shm/rand.dd /dev/shm/rand.dd \
      /dev/shm/rand.dd /dev/shm/rand.dd /dev/shm/rand.dd /dev/shm/rand.dd \
      /dev/shm/rand.dd /dev/shm/rand.dd /dev/shm/rand.dd /dev/shm/rand.dd \
      ....


AJ ONeal


On Fri, Sep 3, 2010 at 11:35 AM, Cole Christensen <chri2586@umn.edu> wrote:
AJ,

I believe your test method is flawed.

My results for a (generic) Class 4 MicroSD on Overo, booted from the SD card:

root@overo:/# dd if=/dev/zero of=/zero.dat bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 190.283 s, 5.5 MB/s

while your cat | dd is still reading from the disk, hence the slowdown.

Yours is a test of copy speed, not pure write speed. 
I am not yet sure if my method is entirely valid either.
Would transferring speed be artificially high when all the bits are zero?


On Fri, Sep 3, 2010 at 11:13 AM, Robert Vogt IV <robert@iosix.com> wrote:
Hi Cole,

Agreed.  I have some numbers for various random number generators on a
16-core Itanium (RHEL 4):

Method  Speed (MB/s)    Speed (MB/s)
               (saving data)   (pure generation)
Urandom 4.19    4.61
System  39.67   250.94
Cran32  37.64   186.29
Lcg     29.16   72.98
Rtprng  40.17   276.17
Isaac   42.07   375.38
Sfmt    43.32   563.38
TR1-MT  29.66   83.17

As you can see, urandom is by far the slowest, followed by random
(random blocks waiting for entropy if necessary, making it quite hard
to get lots of data).  Of course, for write testing, one doesn't even
need random data...


Robert Vogt IV
CEO
IOSiX, LLC
2375 Parkwood Ave
Ypsilanti, MI  48198
robert@iosix.com
P: 734-730-9690
F: 734-482-2337



On Fri, Sep 3, 2010 at 4:49 AM, Cole Christensen <chri2586@umn.edu> wrote:
>
>> root@overo:~# dd if=/dev/urandom of=/media/mmcblk0p1/rand.dd bs=1M
>> count=100
>
> If your input is urandom the bottleneck could be the random number generator
> and not the disk.
>
>>
>>
>>
>> ----- Original Message -----
>> From: AJ ONeal
>> To: General mailing list for gumstix users.
>> Sent: Friday, September 03, 2010 2:25 AM
>> Subject: [Gumstix-users] microSDHC write speed comparison
>> I'm testing out various brands and classes of microSDHC to see which
>> actually perform as they should and whether the microSDHC or the gumstix
>> data bus is my write speed bottleneck.
>> http://fastr.github.com/articles/testing-file-write-speeds.html
>> So far I would recommend Kingston. It's more expensive, but it performs
>> well. I should have a class 10 of theirs soon to test against.
>> AJ ONeal
>>
>> ________________________________
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>>
>> ________________________________
>>
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> gumstix-users mailing list
>> gumstix-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users