-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
Somehow your mail was delayed many hours. | in my gta02v5 I get ~3.2 MB/sec sustained read performace with the | shipped 512 MB sandisk card using e.g. Not bad. | when I do the same with this card in my Lenovo T61p (builtin sd card reader) | I get ~7.5 MB/sec. is there a chance to get better read performace ? Only by doing quite some work. | reading from /dev/mtdblock6 (the internal jffs2 partition?) I also get ~3.2 MB/sec | | any chance to get better read performace (both for SD and the internal flash)? | what's the limiting factor ? Different in each case. SD is hooked through a peripheral chip called "Glamo", it has internal DRAM and performs the bulk transfer from the card to its own RAM autonomously: the CPU gets an interrupt when the bulk data is ready in RAM. Then the CPU basically memcpy's the data back to its own DRAM. NAND has only an 8-bit pipe to the CPU and jffs2 is compressed filesystem so it's not zero-cost for CPU. Currently (although Holger has done patches for HW) we do software ECC on it. | one term seems to be the block size (cp uses 4k I/O blocks): | | # time dd if=/bin/bash of=/media/mmcblk0p2/bin/bash bs=4k | real 0m3.952s | | # time dd if=/bin/bash of=/media/mmcblk0p2/bin/bash bs=64k | real 0m3.020s Interesting. | is this really the max. cpu/system performace for a 400 MHz arm ? No, it's not CPU bound. For "half the time" the CPU is doing other processes waiting for the bulk completion interrupt from Glamo. | talking about cpu performace: a first naiive read-test for /bin/bash | obviously was cpu bound (again, only ~1.4 MB/sec for 400 MHz?!): | | # time wc -l /bin/bash | 9274 /bin/bash | | real 0m0.464s | user 0m0.400s | sys 0m0.030s That's telling you about wc implementation against that chunk of binary data more than anything else I think. | and was surprised that this takes 3.9 to 4.2 seconds for _every_ run | (no caching effect for 2nd run). /bin/ is the internal flash jffs2, | /media/mmcblk0p2/ is ext3. Why would there be a caching effect for the second run? It doesn't know it's the same data. You can confirm that stuff was generally write-cached by doing mount /dev/mmcblk0p2 / -oremount,ro and timing that, it forces a flush. If not, look at your original mount options and see if it has "sync" or so. That was a lot of questions for one email! - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiXQoAACgkQOjLpvpq7dMrEdQCeLh4Q43qX9ZU764qJ00YV4JW6 2uUAoInxk1wjEdiiEjv1FgRd36Hcjp4E =+7I0 -----END PGP SIGNATURE----- _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
