More SD Card issues

Joel Sherrill joel.sherrill at
Thu Oct 16 13:37:55 UTC 2008


Thanks for posting all the info.  One thing I noticed
and changed on the CVS head was that in utils-cp.c,
the read() used MAXBSIZE which is 64K and declares
the buffer as a static variable.  Performing a 64K read/write
would likely put extreme pressure on the buffers
and the lower buffer configurations would very likely
be thrashing. 

I didn't think it was cool to declare a 64K array and,
in fact, this is too large an object on
a few architectures.  I (arbitrarily) lowered it to
1K and meant to email you to check the performance
at various sizes so we could settle on something
reasonable size and (consider) malloc'ing and free it.


Chris Johns wrote:
> Robert S. Grimes wrote:
>> The SD card driver seems to be working pretty well.  A simple test where
>> I write one megabyte of data in 256 byte chunks takes about 57 seconds,
>> for ~18.5 kilobytes/second to disk  This seems pretty reasonable, as the
>> data sheet says the "Block Write Access Time" for "Binary Products" is
>> 24 milliseconds typical, 250 milliseconds max; using the 24 ms for 512
>> byte blocks, which translates to 21,333 kilobytes per second.  Seem right?
> Well done on getting your SD card up and running.
> I can only comment on the performance side of things and it would seem fine
> given the figure you provide. The write of a single file in this way is good
> but a better test is to copy a groups of files. With the right cache setting I
> would hope to see the same performance.
> I did some analysis of the cache once I had completed my changes. I ran my
> tests on a 300MHz Pentium Compact PC with 512M of RAM and a 4.3G Fujitsu
> (MPD3043AT) disk. I formatted the disk using FreeDOS and then copied the
> install directory from the CDROM to disk. I then used the shell in RTEMS to
> make copies of the install directory in a tree layout until I had 26.176M of
> data in 1215 files and 168 directories. One directory had 305 files so this
> pushed the limits on the file system and the cache. The RTEMS shell copy
> command is the BSD shell copy command and it does a couple of stats on the
> directory for a file that is not present and so all 305 entries needed to be
> checked. The table shows the results for various cache sizes:
>            Buffers  RA  WB Time (secs) Rate (KB/sec) Files/sec
> Default     64     32  16     495       52.862        2.45
>             512     32  16     140      186.907        8.68
>             512     64  32     130      201.284        9.35
>            1024     64  32     105      249.209       11.57
> Buffers = number of buffers in the pool (512 bytes)
> RA = number of read-ahead buffers
> WB = number of write-back buffers
> The data rate is half the actual rate on the bus because we had to read this
> data into memory then write it out. The 512K cache did help. An interesting
> thing was the sound of the disk for each of these settings. The default was
> bashing the disk and lots of noise. The last set of values was quiet and the
> disk did not sound under any stress.
> A look at the shell's cpuuse command showed 80% of the time was spent in the
> ATA task, 8% in the file system and copy code and 12% in idle. That idle time
> is interesting and I am not sure why it was there. For this type of disk the
> ATA driver is where the effort would need to be spent to improve performance.
> Regards
> Chris
> _______________________________________________
> rtems-users mailing list
> rtems-users at

Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

More information about the users mailing list