2015-06-20 12:10 AM
Good day,
I have a bit of a problem, is it possible to use SDIO with smaller buffers and have decent speed.I tried to do few tests with smaller buffer like data_buffer[512], data_buffer[1024]...And have really poor speed. My SDIO clock if I remember correctly is 24MHz.512B buffer speed: 84.545532 KB/s, done 8388608 bytes
1024B buffer speed: 242.144394 KB/s, done 8388608 bytes2048B buffer speed: 641.919800 KB/s, done 8388608 bytes4096B buffer speed: 1517.201660 KB/s, done 8388608 bytes8192B buffer speed: 3362.167480 KB/s, done 8388608 bytes16384B buffer speed: 5949.367188 KB/s, done 8388608 bytes32768B buffer speed: 7989.150391 KB/s, done 8388608 bytesThank you,//Nikolaj2015-06-20 07:40 AM
There tends to be a lot of command/protocol overhead, vs streaming data. The SD cards has something like an 8051 processing commands, and care-taking the NAND array, managing blocks, erase, etc. It's not very rapid, and the erase block size is in the order of 128KB. The streaming of the data into internal buffers is quite rapid, in the order of 12 MBps.
You basically need to move away from doing small blocks, either as you buffer the data you want going out, or creating some sort of lazy writer or cache to consolidate blocks going to the media. If I was generating logs files, I would tend to avoid fwrite(), fprintf() type constructs, recording small buffers, into a larger buffer, and once that got sufficiently full flush that to the media. Basically trading the cost of memory-to-memory copies, against the penalty of doing multiple small writes. Obviously the reduce memory in embedded systems tends to skew things also.2015-06-22 01:16 AM
Hum... the most funny thing regarding these figures, is that until the 8KB transfer, the larger the data buffer is the less time it take to access it !!
example: 512B takes around 6ms according your numbers, whereas 8KB take only 2,5ms to access, damn that's devilish ! My only guess ... software issue. OH, BTW what is your driver ? -- Laurent