More SD Card issues

[Joel Sherrill]

Chris,

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.

--joel

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 rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


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