First off, thanks for all the work to get this finished and published and for the support you offer.
Here are my results using a Corsair 512Mbyte 60x SD card.
Clock: 80000000 ClusterSize: 16384 ClusterCount: 30546
Raw write 3968 kB in 2798 ms at 1418 kB/s
Raw read 1920 kB in 2089 ms at 919 kB/s
fsrw pwrite 2016 kB in 3424 ms at 588 kB/s
fsrw pread 2016 kB in 3299 ms at 611 kB/s
FSRW pputc 63 kB in 2122 ms at 29 kB/s
FSRW pgetc 63 kB in 1892 ms at 33 kB/s
All done!
This is using the code at the top of the thread. I'll try the it with the newest version of md_spi and repost. I'm using an SD card adaptor from uController.com on a Prop Proto Board. This includes the pull-up resistors.
First off, thanks for all the work to get this finished and published and for the support you offer.
Hey, no problem. The support at this phase is simply self serving...every problem I can fix now means fewer emails in the future! [noparse][[/noparse]8^)
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Here is my last round of tests. They where done on a Demoboard and Sparkfun MicroSD Breakout board, (which I failed to mention Sparkfun in my last tests). This board would not run the tests before without pullup resistors. These tests were run WITHOUT PULLUPS and with the latest mb_spi.spin. PNY 2GB MicroSD - 80 Mhz
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3337 ms at 1188 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3282 ms at 614 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2137 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
********************************************* Kodak 2GB MicroSD #1 - 80 Mhz
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 3372 ms at 1176 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3445 ms at 585 kB/s
fsrw pread 2016 kB in 3308 ms at 609 kB/s
FSRW pputc 63 kB in 2278 ms at 27 kB/s
FSRW pgetc 63 kB in 1891 ms at 33 kB/s
********************************************* Kodak 2GB MicroSD #2 - 80 Mhz
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3343 ms at 1187 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3286 ms at 613 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2138 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s ******************************************* NEXT TESTS RUNNING AT 100Mhz ******************************************* PNY 2GB MicroSD - 100 Mhz
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2864 ms at 1385 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2706 ms at 744 kB/s
fsrw pread 2016 kB in 2652 ms at 760 kB/s
FSRW pputc 127 kB in 3438 ms at 36 kB/s
FSRW pgetc 127 kB in 3051 ms at 41 kB/s
*******************************************
Kodak 2GB MicroSD #1 -·100 Mhz
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2863 ms at 1385 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2599 ms at 775 kB/s
fsrw pread 2016 kB in 2652 ms at 760 kB/s
FSRW pputc 127 kB in 3439 ms at 36 kB/s
FSRW pgetc 127 kB in 3051 ms at 41 kB/s
********************************************
Kodak 2GB MicroSD #2 -·100 Mhz
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 2915 ms at 1361 kB/s
Raw read 3968 kB in 3494 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2695 ms at 747 kB/s
fsrw pread 2016 kB in 2647 ms at 761 kB/s
FSRW pputc 127 kB in 3575 ms at 35 kB/s
FSRW pgetc 127 kB in 3049 ms at 41 kB/s
Thanks to lonesock and rokicki, and thanks for turning me on to PropViewer, (GREAT terminal Praxis!)
100Mhz and not looking back! Thanks to Bill for sourcing those!
Cheers,
Jim
lonesock said...
Hi, All.
OK, here's the update: Attached to this post I'm including a new version of mb_spi.spin, which I'm asking anyone who can to try out. Here's what's different.
Thanks for your patience, everyone. If this test version works on everybody's setup, then I'll start stripping out the extraneous debug info and bring the speed back up.
hover1 said...
...
Thanks to lonesock and rokicki, and thanks for turning me on to PropViewer, (GREAT terminal Praxis!)
100Mhz and not looking back! Thanks to Bill for sourcing those!
Cheers,
Jim
Thanks, Jim!
@All: just a little teaser...I now have 1-instruction-per-bit reads working on both my SD-capable systems at PLL16X (1 at 80MHz with a 9" long ribbon cable connecting the SD socket, and 1 at 100MHz with a uSD socket on a PCB). I need to do some more internal testing and let a few brave souls pound on it for a while, to make sure it is solid on more than 2 systems. If it is solid, then I'll release it into the wild, otherwise it will be posted with huge warning signs [noparse][[/noparse]8^).
Anyway, here are my numbers for a SanDisk 2GB SD on my 80MHz system:
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62022
Raw write 3968 kB in 2733 ms at 1451 kB/s
Raw read 3968 kB in 2910 ms at 1363 kB/s
fsrw pwrite 2016 kB in 2903 ms at 694 kB/s
fsrw pread 2016 kB in 2572 ms at 783 kB/s
FSRW pputc 63 kB in 2154 ms at 29 kB/s
FSRW pgetc 63 kB in 1869 ms at 33 kB/s
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Hi,
please find attached the results with my bigger SD cards (empty):
Sandisk SDHC 4Gb
Clock: 80000000 ClusterSize: 32768 ClusterCount: 120754
Raw write 3968 kB in 2903 ms at 1366 kB/s
Raw read 1920 kB in 2076 ms at 924 kB/s
fsrw pwrite 2016 kB in 2741 ms at 735 kB/s
fsrw pread 2016 kB in 3277 ms at 615 kB/s
FSRW pputc 63 kB in 2146 ms at 29 kB/s
FSRW pgetc 63 kB in 1892 ms at 33 kB/s
Sandisk Ultra 2 SDHC 16Gb
Clock: 80000000 ClusterSize: 32768 ClusterCount: 499410
Raw write 3968 kB in 2696 ms at 1471 kB/s
Raw read 1920 kB in 2076 ms at 924 kB/s
fsrw pwrite 2016 kB in 3115 ms at 647 kB/s
fsrw pread 2016 kB in 3276 ms at 615 kB/s
FSRW pputc 63 kB in 2198 ms at 28 kB/s
FSRW pgetc 63 kB in 1892 ms at 33 kB/s
I want to make sure everyone knows this is not yet a blessed release. You use it at your own risk.
We very much appreciate the testing, but do *not* use this code in any sort of production environment
or product until we have released a blessed release.
In that case, I'd recommend rolling back to fsrw1.6 if at all possible (even though it's slower and not as featureful, and even
though fsrw1.6 as released contains a bug having to do with empty files.) Or you can go forward at your own risk, but the
code *does* have our name on it so we'd prefer you not do that.
We have at least one issue we are trying to understand; this issue may be a significant one. We simply need more testing
before we can endorse this release.
Kodak shows:
15.7% improvement on raw write
25.1% improvement on raw read
21.8% on fsrw pwrite
25.0% on fsrw pread
24.1% on pputc
24.2% on pgetc
hover1 said...
Here is my last round of tests. They where done on a Demoboard and Sparkfun MicroSD Breakout board, (which I failed to mention Sparkfun in my last tests). This board would not run the tests before without pullup resistors. These tests were run WITHOUT PULLUPS and with the latest mb_spi.spin.
Kodak 2GB MicroSD #1 - 80 Mhz
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 3372 ms at 1176 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
<FONT color=#0000ff>Kodak 2GB MicroSD #2 - 100 Mhz
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 2915 ms at 1361 kB/s
Raw read 3968 kB in 3494 ms at 1135 kB/s
Thanks to lonesock and rokicki, and thanks for turning me on to PropViewer, (GREAT terminal Praxis!)
100Mhz and not looking back! Thanks to Bill for sourcing those!
Cheers,
Jim
lonesock said...
Hi, All.
OK, here's the update: Attached to this post I'm including a new version of mb_spi.spin, which I'm asking anyone who can to try out. Here's what's different.
Thanks for your patience, everyone. If this test version works on everybody's setup, then I'll start stripping out the extraneous debug info and bring the speed back up.
@Rayman: Your enthusiasm is infectious! The warning notice is great, thanks.
@All, just to give you a quick update:
- The 1 instruction per bit reads are working! Read speed is much improved.
- Multiple files are working.
- We're working on a simple serial terminal type test framework for doing common tasks (copy A B, concat A B C D E sum.txt, etc.)
And you all know you can monitor our progress from the SourceForge website, right? fsrw.hg.sourceforge.net/hgweb/fsrw/
(You can also watch our TODO file to see where we want to go...note that the order each item is listed is not necessarily indicative of its implementation priority.)
thanks for your patience,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
[noparse][[/noparse]New fsrw23.zip posted at the top of the thread.]
Another test release of fsrw23; this one supports multiple files (see serial_terminal.spin
for an example), and it's substantially faster when using pread/pwrite.
On my 100MHz demo board, I now get 1.3MB/sec writes, 1.6MB/sec reads when using
pread/pwrite; the raw reads and writes are above 2MB/sec.
We are approaching a blessed release. Give this one a spin and see if you can break it.
Here are my results for a SanDisk 2GB SD card (class 4), with the prop running at 80MHz:
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62022
Raw write 3968 kB in 2276 ms at 1743 kB/s
Raw read 3968 kB in 2353 ms at 1686 kB/s
fsrw pwrite 4064 kB in 4158 ms at 977 kB/s
fsrw pread 4064 kB in 3206 ms at 1267 kB/s
FSRW pputc 63 kB in 2114 ms at 29 kB/s
FSRW pgetc 63 kB in 1839 ms at 34 kB/s
All done!
Hopefully this version works for everybody!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Canon 16M, FAT16 not reformatted
Demoboard @80MHz, uController.com card w/ wirewrap jumpers, frsw 2.3
Clock: 80000000 ClusterSize: 512 ClusterCount: 28801
Raw write 3968 kB in 2853 ms at 1391 kB/s
Raw read 3968 kB in 2470 ms at 1606 kB/s
fsrw pwrite 224 kB in 2980 ms at 75 kB/s
fsrw pread 224 kB in 279 ms at 804 kB/s
FSRW pputc 63 kB in 3160 ms at 19 kB/s
FSRW pgetc 63 kB in 1876 ms at 33 kB/s
Huh. My raw read/write numbers aren't that much different than yours but the pwrite is much worse. Is this clustersize?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
ericball said...
...
Clock: 80000000 ClusterSize: 512 ClusterCount: 28801
...
Huh. My raw read/write numbers aren't that much different than yours but the pwrite is much worse. Is this clustersize?
Definitely! I have never seen ClusterSize below 4k [noparse][[/noparse]8^).
<edit>For a 16MB card, I think the max size you can do is 2k, but it should still be an improvement!</edit>
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Right, I can't emphasize enough, use as big a clustersize as you can.
In order to achieve a 32K cluster size, you need a minimum of a 256M card
in order to keep it FAT16.
I would not use any old cards smaller than 256MB if you care about
performance at all; cluster sizes below 32K have a huge negative effect
on performance, both read and write.
The best cards will be 2GB cards formatted as FAT16 using a 32K cluster
size. (FAT32 introduces some additional overhead over FAT16.) These
cards are presently less than $10 most places.
Of course, if you don't care about performance, and for many applications
it won't matter, use whatever you want. But otherwise, spend the $10 and
get a 2GB card, format it with 32K clusters, and fly.
Hi guys, don't want to disrupt things, but I'm currently doing a little game for a single Prop board with SD, now here's the funny issue!
I'm currently using the old FSRW and it works fine!
I swapped over to FSRW23 this morning and it no longer works! swap back to old FSRW and it works, again swapped to new FSRW and it doesn't work.
keeps locking up on Mount!
Baggers said...
Hi guys, don't want to disrupt things, but I'm currently doing a little game for a single Prop board with SD, now here's the funny issue!
I'm currently using the old FSRW and it works fine!
I swapped over to FSRW23 this morning and it no longer works! swap back to old FSRW and it works, again swapped to new FSRW and it doesn't work.
keeps locking up on Mount!
I've done some other tests also, with FSRW23 it works on power off/power on, but from reset, or re-program from prop plug it doesn't work. ( hope this helps )
I've done some other tests also, with FSRW23 it works on power off/power on, but from reset, or re-program from prop plug it doesn't work. ( hope this helps )
Baggers.
I have found that a small percentage of cards refuse to reset if left in a multiblock mode (either read or write), which the latest version uses. If you either unmount after using the fsrw routines, or less intrusive, call the public "release" method of the underlying block layer after you are done reading or writing to the card, I'm betting that your card will come up fine on a re-program. The block layer is set up as a singleton, so feel free to include a copy of mb_rawb_spi.spin in the same object as fsrw, and call the release function directly.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
If you're willing to PM your source to me (I promise I won't share it with anyone), and assuming I can
modify it to work (or at least replicate the issue) on my demo board, that would be very helpful.
My PM is the username I use here, but at gmail.
(Please don't use the forum messages; those I find very awkward.)
Even if you don't unmount, the fsrw23 *should* work; it works on the 20 cards I've tried here.
If you would be willing to do some experiments, these are what I'd be interested in seeing:
1. Try using mb_small_spi.spin instead of mb_rawb_spi.spin and see if that helps.
2. Try using mb_spi.spin instead of mb_rawb_spi.spin and see if that helps.
3. Try running "test.spin" (with suitable changes to sysdep.spin) and see if your card
passes the mount tests (which presumably test things like leaving the card in various
modes and trying to reinitialize).
4. Try a different sd card (preferably a different brand and size).
It's painful, but finding cases where things fail and fixing them is really exactly why we
are posting the code we have posted. Rest assured we test the code pretty darned
thoroughly before even posting it here, so your efforts are important.
About small cluster sizes... I wrote a function that gives you the amount of free space on the partition by scanning the FAT. In testing I noticed that when using a FAT16 2gb SD card the function took about 1min.
However, on FAT32 it took about 10min.
Why? Because the FAT16 cluster size was 32kb but the FAT32 cluster size was 4Kb.
But, you can always tell windows what cluster size it should use for files and what type of FAT to format the card in.
Remeber folks - The bigger the cluster size the better!
Latest Test of FSRW2.3 Media formatted for first test only.
Parallax Standard Demo Board. No Pullups. Standard 5Mhz xtal. Basepin 0. Two·test per device, (this is what·PropViewer does (double CR·I guess, not too worried about it right now), I did not include the double test results before, but I will do so here.)
PNY 2G MicroSD Power On, Download to EEPROM·and Run Test
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3362 ms at 1180 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 2959 ms at 681 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2131 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3407 ms at 1164 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3114 ms at 647 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1897 ms at 33 kB/s
PNY 2G MicroSD Power OFF-Power On,·and Run Test (From EEPEOM)
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3538 ms at 1121 kB/s
Raw read 1920 kB in 2114 ms at 908 kB/s
fsrw pwrite 2016 kB in 2976 ms at 677 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2131 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
All done!
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3407 ms at 1164 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3109 ms at 648 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1897 ms at 33 kB/s
PNY 2G MicroSD·Reset from Propview,·and Run Test (From EEPEOM)
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3413 ms at 1162 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3115 ms at 647 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2131 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3414 ms at 1162 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3111 ms at 647 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1897 ms at 33 kB/s
Will test·Kodak cards and 100 MHz·Sunday.
Hungry, must eat.
Jim···
rokicki said...
[noparse][[/noparse]New fsrw23.zip posted at the top of the thread.]
Another test release of fsrw23; this one supports multiple files (see serial_terminal.spin
for an example), and it's substantially faster when using pread/pwrite.
On my 100MHz demo board, I now get 1.3MB/sec writes, 1.6MB/sec reads when using
pread/pwrite; the raw reads and writes are above 2MB/sec.
We are approaching a blessed release. Give this one a spin and see if you can break it.
It works now ( only with using mp_small_spi ) thanks [noparse]:)[/noparse]
On a side note, I tried using the test and that works with mb_spi and mb_rawb_spi, but if I try test with mb_small_spi I get
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 3968 kB in 3724 ms at 1065 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 1920 kB in 2563 ms at 748 kB/s
Now the filesystem tests
Trying to mount
Erroneously returned from start!
-20
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3395 ms at 1168 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3099 ms at 650 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2135 ms at 29 kB/s
FSRW pgetc 63 kB in 1896 ms at 33 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3401 ms at 1166 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 2988 ms at 674 kB/s
fsrw pread 2016 kB in 3314 ms at 608 kB/s
FSRW pputc 63 kB in 2233 ms at 28 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3356 ms at 1182 kB/s
Raw read 3968 kB in 2913 ms at 1362 kB/s
fsrw pwrite 2016 kB in 2059 ms at 978 kB/s
fsrw pread 2016 kB in 1592 ms at 1266 kB/s
FSRW pputc 63 kB in 2106 ms at 29 kB/s
FSRW pgetc 63 kB in 1843 ms at 34 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3354 ms at 1182 kB/s
Raw read 3968 kB in 2913 ms at 1362 kB/s
fsrw pwrite 2016 kB in 2070 ms at 973 kB/s
fsrw pread 2016 kB in 1592 ms at 1265 kB/s
FSRW pputc 63 kB in 2106 ms at 29 kB/s
FSRW pgetc 63 kB in 1843 ms at 34 kB/s
Why such a big difference in the "Raw Read" and "pread"?
Jim
rokicki said...
[noparse][[/noparse]New fsrw23.zip posted at the top of the thread.]
Another test release of fsrw23; this one supports multiple files (see serial_terminal.spin
for an example), and it's substantially faster when using pread/pwrite.
On my 100MHz demo board, I now get 1.3MB/sec writes, 1.6MB/sec reads when using
pread/pwrite; the raw reads and writes are above 2MB/sec.
We are approaching a blessed release. Give this one a spin and see if you can break it.
@Baggers: The three versions do not do the same thing, but all three versions use multiblock mode.
- mb_small_spi is out of date (not sure exactly what's been changed, though)
- mb_spi does not do read-ahead (RA) and write-behind (WB), but is up-to-date
- mb_rawb_spi implements the latest RA & WB functions
Could you try using the block layer's release command after reading or writing a file, in conjunction with the mb_rawb_spi code and let me know if that works?
@Jim: Those numbers are almost exactly backwards from the numbers I am getting. On my 80MHz system, the mb_rawb_spi module usually gives me around 950 KB/s pwrite speed (at 32k cluster size), and 1250 KB/s pread speed. Could you check whichever version of the block layer is fast, and see if it has a PASM function named "read_ahead"? Also, could you verify that both the raw block layer in test.spin, and the block layer as used inside fsrw.spin are the same?
Thanks for trying this out, everybody!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
lonesock said...
@Jim: Those numbers are almost exactly backwards from the numbers I am getting. On my 80MHz system, the mb_rawb_spi module usually gives me around 950 KB/s pwrite speed (at 32k cluster size), and 1250 KB/s pread speed. Could you check whichever version of the block layer is fast, and see if it has a PASM function named "read_ahead"? Also, could you verify that both the raw block layer in test.spin, and the block layer as used inside fsrw.spin are the same?
Thanks for trying this out, everybody!
Jonathan
Jonathan,
Gosh, I love your passion with this!
I'll do a quick ckeck on the block layer version. Hopefully by tonight (US central time).
It may take me a few days to do the tests as requested.
I have a deadline to meet on·Tuesday for another project.
I want to set aside two·boards to do the tests and strip them down to just support the MiroSD and nothing else. Don't want other components skewing the results.
@Jim: Those numbers are almost exactly backwards from the numbers I am getting. On my 80MHz system, the mb_rawb_spi module usually gives me around 950 KB/s pwrite speed (at 32k cluster size), and 1250 KB/s pread speed. Could you check whichever version of the block layer is fast, and see if it has a PASM function named "read_ahead"? Also, could you verify that both the raw block layer in test.spin, and the block layer as used inside fsrw.spin are the same?
Thanks for trying this out, everybody!
Jonathan
Jonathan,
Gosh, I love your passion with this!
I'll do a quick ckeck on the block layer version. Hopefully by tonight (US central time).
It may take me a few days to do the tests as requested.
I have a deadline to meet on Tuesday for another project.
I want to set aside two boards to do the tests and strip them down to just support the MiroSD and nothing else. Don't want other components skewing the results.
Jim
Thanks, Jim!
OK, quick note to everybody, I am working on 3 things:
1 - I am adding a release command to pclose in fsrw, and I am adding a "release on idle" to the multiblock driver (say after 100ms...but user settable). This should make the chances of the card getting left in a multiblock mode very slim.
2 - I have a single-block mode driver ready to go, for anyone whose application absolutely cannot guarantee being able to call "release" or pclose or unmount after data access. Note: for all the SDHC cards I own, writing performance is abysmal using single block layer. E.g. 50 KB/s raw write speed! If you are going to support SDHC cards and FAT32 in your application, you really really really want to use the multiblock driver, if at all possible.
3 - I will start working on a mini-whitepaper detailing the structure I used in the multiblock layer, the reasoning behind it, how to tweak, and some suggestions for getting the absolute best performance out of your card. Hopefully this will shed some light on what I'm doing and why, and be a good starting point for anyone wishing to modify the code, or port it, or whatever.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
lonesock,·I put a release command after the·pclose and it works now with mp_rawb_spi·[noparse]:D[/noparse]
Thanks,
Baggers.
lonesock said...
@Baggers: The three versions do not do the same thing, but all three versions use multiblock mode.
- mb_small_spi is out of date (not sure exactly what's been changed, though)
- mb_spi does not do read-ahead (RA) and write-behind (WB), but is up-to-date
- mb_rawb_spi implements the latest RA & WB functions
Could you try using the block layer's release command after reading or writing a file, in conjunction with the mb_rawb_spi code and let me know if that works?
@Jim: Those numbers are almost exactly backwards from the numbers I am getting. On my 80MHz system, the mb_rawb_spi module usually gives me around 950 KB/s pwrite speed (at 32k cluster size), and 1250 KB/s pread speed. Could you check whichever version of the block layer is fast, and see if it has a PASM function named "read_ahead"? Also, could you verify that both the raw block layer in test.spin, and the block layer as used inside fsrw.spin are the same?
Comments
First off, thanks for all the work to get this finished and published and for the support you offer.
Here are my results using a Corsair 512Mbyte 60x SD card.
Clock: 80000000 ClusterSize: 16384 ClusterCount: 30546
Raw write 3968 kB in 2798 ms at 1418 kB/s
Raw read 1920 kB in 2089 ms at 919 kB/s
fsrw pwrite 2016 kB in 3424 ms at 588 kB/s
fsrw pread 2016 kB in 3299 ms at 611 kB/s
FSRW pputc 63 kB in 2122 ms at 29 kB/s
FSRW pgetc 63 kB in 1892 ms at 33 kB/s
All done!
This is using the code at the top of the thread. I'll try the it with the newest version of md_spi and repost. I'm using an SD card adaptor from uController.com on a Prop Proto Board. This includes the pull-up resistors.
Thanks again,
pgbpsu
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
PNY 2GB MicroSD - 80 Mhz
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3337 ms at 1188 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3282 ms at 614 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2137 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
*********************************************
Kodak 2GB MicroSD #1 - 80 Mhz
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 3372 ms at 1176 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3445 ms at 585 kB/s
fsrw pread 2016 kB in 3308 ms at 609 kB/s
FSRW pputc 63 kB in 2278 ms at 27 kB/s
FSRW pgetc 63 kB in 1891 ms at 33 kB/s
*********************************************
Kodak 2GB MicroSD #2 - 80 Mhz
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3343 ms at 1187 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3286 ms at 613 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2138 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
*******************************************
NEXT TESTS RUNNING AT 100Mhz
*******************************************
PNY 2GB MicroSD - 100 Mhz
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2864 ms at 1385 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2706 ms at 744 kB/s
fsrw pread 2016 kB in 2652 ms at 760 kB/s
FSRW pputc 127 kB in 3438 ms at 36 kB/s
FSRW pgetc 127 kB in 3051 ms at 41 kB/s
*******************************************
Kodak 2GB MicroSD #1 -·100 Mhz
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 2863 ms at 1385 kB/s
Raw read 3968 kB in 3493 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2599 ms at 775 kB/s
fsrw pread 2016 kB in 2652 ms at 760 kB/s
FSRW pputc 127 kB in 3439 ms at 36 kB/s
FSRW pgetc 127 kB in 3051 ms at 41 kB/s
********************************************
Kodak 2GB MicroSD #2 -·100 Mhz
Clock: 100000000 ClusterSize: 32768 ClusterCount: 62294
Raw write 3968 kB in 2915 ms at 1361 kB/s
Raw read 3968 kB in 3494 ms at 1135 kB/s
fsrw pwrite 2016 kB in 2695 ms at 747 kB/s
fsrw pread 2016 kB in 2647 ms at 761 kB/s
FSRW pputc 127 kB in 3575 ms at 35 kB/s
FSRW pgetc 127 kB in 3049 ms at 41 kB/s
Thanks to lonesock and rokicki, and thanks for turning me on to PropViewer, (GREAT terminal Praxis!)
100Mhz and not looking back! Thanks to Bill for sourcing those!
Cheers,
Jim
@All: just a little teaser...I now have 1-instruction-per-bit reads working on both my SD-capable systems at PLL16X (1 at 80MHz with a 9" long ribbon cable connecting the SD socket, and 1 at 100MHz with a uSD socket on a PCB). I need to do some more internal testing and let a few brave souls pound on it for a while, to make sure it is solid on more than 2 systems. If it is solid, then I'll release it into the wild, otherwise it will be posted with huge warning signs [noparse][[/noparse]8^).
Anyway, here are my numbers for a SanDisk 2GB SD on my 80MHz system:
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62022
Raw write 3968 kB in 2733 ms at 1451 kB/s
Raw read 3968 kB in 2910 ms at 1363 kB/s
fsrw pwrite 2016 kB in 2903 ms at 694 kB/s
fsrw pread 2016 kB in 2572 ms at 783 kB/s
FSRW pputc 63 kB in 2154 ms at 29 kB/s
FSRW pgetc 63 kB in 1869 ms at 33 kB/s
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
please find attached the results with my bigger SD cards (empty):
Sandisk SDHC 4Gb
Clock: 80000000 ClusterSize: 32768 ClusterCount: 120754
Raw write 3968 kB in 2903 ms at 1366 kB/s
Raw read 1920 kB in 2076 ms at 924 kB/s
fsrw pwrite 2016 kB in 2741 ms at 735 kB/s
fsrw pread 2016 kB in 3277 ms at 615 kB/s
FSRW pputc 63 kB in 2146 ms at 29 kB/s
FSRW pgetc 63 kB in 1892 ms at 33 kB/s
Sandisk Ultra 2 SDHC 16Gb
Clock: 80000000 ClusterSize: 32768 ClusterCount: 499410
Raw write 3968 kB in 2696 ms at 1471 kB/s
Raw read 1920 kB in 2076 ms at 924 kB/s
fsrw pwrite 2016 kB in 3115 ms at 647 kB/s
fsrw pread 2016 kB in 3276 ms at 615 kB/s
FSRW pputc 63 kB in 2198 ms at 28 kB/s
FSRW pgetc 63 kB in 1892 ms at 33 kB/s
Massimo
We very much appreciate the testing, but do *not* use this code in any sort of production environment
or product until we have released a blessed release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
though fsrw1.6 as released contains a bug having to do with empty files.) Or you can go forward at your own risk, but the
code *does* have our name on it so we'd prefer you not do that.
We have at least one issue we are trying to understand; this issue may be a significant one. We simply need more testing
before we can endorse this release.
Great results... will get even better at 1bit/ins
Kodak shows:
15.7% improvement on raw write
25.1% improvement on raw read
21.8% on fsrw pwrite
25.0% on fsrw pread
24.1% on pputc
24.2% on pgetc
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
"Note: This file contains a preliminary new release of the SD card driver. Use with caution!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
@Bill: Ditto!
@Rayman: Your enthusiasm is infectious! The warning notice is great, thanks.
@All, just to give you a quick update:
- The 1 instruction per bit reads are working! Read speed is much improved.
- Multiple files are working.
- We're working on a simple serial terminal type test framework for doing common tasks (copy A B, concat A B C D E sum.txt, etc.)
And you all know you can monitor our progress from the SourceForge website, right?
fsrw.hg.sourceforge.net/hgweb/fsrw/
(You can also watch our TODO file to see where we want to go...note that the order each item is listed is not necessarily indicative of its implementation priority.)
thanks for your patience,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Another test release of fsrw23; this one supports multiple files (see serial_terminal.spin
for an example), and it's substantially faster when using pread/pwrite.
On my 100MHz demo board, I now get 1.3MB/sec writes, 1.6MB/sec reads when using
pread/pwrite; the raw reads and writes are above 2MB/sec.
We are approaching a blessed release. Give this one a spin and see if you can break it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Here are my results for a SanDisk 2GB SD card (class 4), with the prop running at 80MHz:
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62022
Raw write 3968 kB in 2276 ms at 1743 kB/s
Raw read 3968 kB in 2353 ms at 1686 kB/s
fsrw pwrite 4064 kB in 4158 ms at 977 kB/s
fsrw pread 4064 kB in 3206 ms at 1267 kB/s
FSRW pputc 63 kB in 2114 ms at 29 kB/s
FSRW pgetc 63 kB in 1839 ms at 34 kB/s
All done!
Hopefully this version works for everybody!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Demoboard @80MHz, uController.com card w/ wirewrap jumpers, frsw 2.3
Clock: 80000000 ClusterSize: 512 ClusterCount: 28801
Raw write 3968 kB in 2853 ms at 1391 kB/s
Raw read 3968 kB in 2470 ms at 1606 kB/s
fsrw pwrite 224 kB in 2980 ms at 75 kB/s
fsrw pread 224 kB in 279 ms at 804 kB/s
FSRW pputc 63 kB in 3160 ms at 19 kB/s
FSRW pgetc 63 kB in 1876 ms at 33 kB/s
Huh. My raw read/write numbers aren't that much different than yours but the pwrite is much worse. Is this clustersize?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
<edit>For a 16MB card, I think the max size you can do is 2k, but it should still be an improvement!</edit>
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Post Edited (lonesock) : 7/25/2009 6:41:21 PM GMT
In order to achieve a 32K cluster size, you need a minimum of a 256M card
in order to keep it FAT16.
I would not use any old cards smaller than 256MB if you care about
performance at all; cluster sizes below 32K have a huge negative effect
on performance, both read and write.
The best cards will be 2GB cards formatted as FAT16 using a 32K cluster
size. (FAT32 introduces some additional overhead over FAT16.) These
cards are presently less than $10 most places.
Of course, if you don't care about performance, and for many applications
it won't matter, use whatever you want. But otherwise, spend the $10 and
get a 2GB card, format it with 32K clusters, and fly.
I'm currently using the old FSRW and it works fine!
I swapped over to FSRW23 this morning and it no longer works! swap back to old FSRW and it works, again swapped to new FSRW and it doesn't work.
keeps locking up on Mount!
Any ideas?
It's on Hybrid, 96Mhz, 6Mhz clk 16*pll.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I've done some other tests also, with FSRW23 it works on power off/power on, but from reset, or re-program from prop plug it doesn't work. ( hope this helps )
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
modify it to work (or at least replicate the issue) on my demo board, that would be very helpful.
My PM is the username I use here, but at gmail.
(Please don't use the forum messages; those I find very awkward.)
Even if you don't unmount, the fsrw23 *should* work; it works on the 20 cards I've tried here.
If you would be willing to do some experiments, these are what I'd be interested in seeing:
1. Try using mb_small_spi.spin instead of mb_rawb_spi.spin and see if that helps.
2. Try using mb_spi.spin instead of mb_rawb_spi.spin and see if that helps.
3. Try running "test.spin" (with suitable changes to sysdep.spin) and see if your card
passes the mount tests (which presumably test things like leaving the card in various
modes and trying to reinitialize).
4. Try a different sd card (preferably a different brand and size).
It's painful, but finding cases where things fail and fixing them is really exactly why we
are posting the code we have posted. Rest assured we test the code pretty darned
thoroughly before even posting it here, so your efforts are important.
About small cluster sizes... I wrote a function that gives you the amount of free space on the partition by scanning the FAT. In testing I noticed that when using a FAT16 2gb SD card the function took about 1min.
However, on FAT32 it took about 10min.
Why? Because the FAT16 cluster size was 32kb but the FAT32 cluster size was 4Kb.
But, you can always tell windows what cluster size it should use for files and what type of FAT to format the card in.
Remeber folks - The bigger the cluster size the better!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Parallax Standard Demo Board. No Pullups. Standard 5Mhz xtal. Basepin 0. Two·test per device, (this is what·PropViewer does (double CR·I guess, not too worried about it right now), I did not include the double test results before, but I will do so here.)
PNY 2G MicroSD Power On, Download to EEPROM·and Run Test
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3362 ms at 1180 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 2959 ms at 681 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2131 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3407 ms at 1164 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3114 ms at 647 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1897 ms at 33 kB/s
PNY 2G MicroSD Power OFF-Power On,·and Run Test (From EEPEOM)
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3538 ms at 1121 kB/s
Raw read 1920 kB in 2114 ms at 908 kB/s
fsrw pwrite 2016 kB in 2976 ms at 677 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2131 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
All done!
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3407 ms at 1164 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3109 ms at 648 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1897 ms at 33 kB/s
PNY 2G MicroSD·Reset from Propview,·and Run Test (From EEPEOM)
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3413 ms at 1162 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3115 ms at 647 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2131 ms at 29 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3414 ms at 1162 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3111 ms at 647 kB/s
fsrw pread 2016 kB in 3313 ms at 608 kB/s
FSRW pputc 63 kB in 2136 ms at 29 kB/s
FSRW pgetc 63 kB in 1897 ms at 33 kB/s
Will test·Kodak cards and 100 MHz·Sunday.
Hungry, must eat.
Jim···
It works now ( only with using mp_small_spi ) thanks [noparse]:)[/noparse]
On a side note, I tried using the test and that works with mb_spi and mb_rawb_spi, but if I try test with mb_small_spi I get
Mount tests first
First mount.
Succeeded; stopping cog.
Second mount.
Succeeded.
Reading block 0 (should be a boot block)
Read finished; checking for boot block signature
Boot block checks out; unmounting
Third mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Boot block checks out; writing it back
Write finished; unmounting
Fourth mount.
Succeeded.
Reading block 0 again (should still be a boot block)
Read finished; checking for boot block signature
Block layer seems to check out
Now speed tests
How fast can we write, sequentially?
Raw write 3968 kB in 3724 ms at 1065 kB/s
Do a single non-sequential write...Done
How fast can we read, sequentially?
Raw read 1920 kB in 2563 ms at 748 kB/s
Now the filesystem tests
Trying to mount
Erroneously returned from start!
-20
hope this helps.
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Using mb_rawb_spi.spin
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3395 ms at 1168 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 3099 ms at 650 kB/s
fsrw pread 2016 kB in 3311 ms at 608 kB/s
FSRW pputc 63 kB in 2135 ms at 29 kB/s
FSRW pgetc 63 kB in 1896 ms at 33 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3401 ms at 1166 kB/s
Raw read 1920 kB in 2115 ms at 907 kB/s
fsrw pwrite 2016 kB in 2988 ms at 674 kB/s
fsrw pread 2016 kB in 3314 ms at 608 kB/s
FSRW pputc 63 kB in 2233 ms at 28 kB/s
FSRW pgetc 63 kB in 1893 ms at 33 kB/s
***********************************************************************
Using mb_spi.spin
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3356 ms at 1182 kB/s
Raw read 3968 kB in 2913 ms at 1362 kB/s
fsrw pwrite 2016 kB in 2059 ms at 978 kB/s
fsrw pread 2016 kB in 1592 ms at 1266 kB/s
FSRW pputc 63 kB in 2106 ms at 29 kB/s
FSRW pgetc 63 kB in 1843 ms at 34 kB/s
Clock: 80000000 ClusterSize: 32768 ClusterCount: 62293
Raw write 3968 kB in 3354 ms at 1182 kB/s
Raw read 3968 kB in 2913 ms at 1362 kB/s
fsrw pwrite 2016 kB in 2070 ms at 973 kB/s
fsrw pread 2016 kB in 1592 ms at 1265 kB/s
FSRW pputc 63 kB in 2106 ms at 29 kB/s
FSRW pgetc 63 kB in 1843 ms at 34 kB/s
Why such a big difference in the "Raw Read" and "pread"?
Jim
- mb_small_spi is out of date (not sure exactly what's been changed, though)
- mb_spi does not do read-ahead (RA) and write-behind (WB), but is up-to-date
- mb_rawb_spi implements the latest RA & WB functions
Could you try using the block layer's release command after reading or writing a file, in conjunction with the mb_rawb_spi code and let me know if that works?
@Jim: Those numbers are almost exactly backwards from the numbers I am getting. On my 80MHz system, the mb_rawb_spi module usually gives me around 950 KB/s pwrite speed (at 32k cluster size), and 1250 KB/s pread speed. Could you check whichever version of the block layer is fast, and see if it has a PASM function named "read_ahead"? Also, could you verify that both the raw block layer in test.spin, and the block layer as used inside fsrw.spin are the same?
Thanks for trying this out, everybody!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Gosh, I love your passion with this!
I'll do a quick ckeck on the block layer version. Hopefully by tonight (US central time).
It may take me a few days to do the tests as requested.
I have a deadline to meet on·Tuesday for another project.
I want to set aside two·boards to do the tests and strip them down to just support the MiroSD and nothing else. Don't want other components skewing the results.
Jim
Post Edited (hover1) : 7/27/2009 11:56:07 AM GMT
OK, quick note to everybody, I am working on 3 things:
1 - I am adding a release command to pclose in fsrw, and I am adding a "release on idle" to the multiblock driver (say after 100ms...but user settable). This should make the chances of the card getting left in a multiblock mode very slim.
2 - I have a single-block mode driver ready to go, for anyone whose application absolutely cannot guarantee being able to call "release" or pclose or unmount after data access. Note: for all the SDHC cards I own, writing performance is abysmal using single block layer. E.g. 50 KB/s raw write speed! If you are going to support SDHC cards and FAT32 in your application, you really really really want to use the multiblock driver, if at all possible.
3 - I will start working on a mini-whitepaper detailing the structure I used in the multiblock layer, the reasoning behind it, how to tweak, and some suggestions for getting the absolute best performance out of your card. Hopefully this will shed some light on what I'm doing and why, and be a good starting point for anyone wishing to modify the code, or port it, or whatever.
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Thanks,
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·