SD card performace ?

[Andy Green]

-----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-----