SD card performace ?

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> 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.
|
| Wait, writes go into a buffer after being ECC'ed and compressed, but
| before being sent to the sd device, right?

No, ECC belongs to NAND world.  There is no ECC involved on external
side of SD (which is one reason to prefer it over raw NAND).  The
original poster asks about both worlds at once.

| The usual rule of thumb is one outstanding write per wire.  So for a
| desktop computer, you need might need to maintain three outstanding
| writes:  one for the PCI bus, one for the sata cable, and one for the
| drive head.
|
| If we have such a buffer, one page in the buffer is used for s/w ecc,
| compression, etc, and one for the card to write data from.  This

Neither ECC nor compression exist for us in SD Card context.

| overlaps SD write time with CPU mucking with data time, so the total
| time should be "max(CPU time, SD time)", not "CPU time + SD time", and
| software ECC shouldn't affect read performance, unless the cpu is at
| 100% during the test.
|
| If we're overlapping I/O and CPU, and the CPU is not at 100%, shouldn't
| the I/O bandwidth be the minimum of the bus bandwidth and the sd card
| bandwidth?

CPU is either idle waiting for notification interrupt that the packet is
in Glamo RAM, or pulling the packet from Glamo RAM.  When the CPU is
idle, it's running other scheduled tasks.

For NAND which does have ECC and compression, there's hardware ECC
already available, but it's problematic since it uses different ECC than
what we use currently AIUI.

Over time it's likely we'll tweak things.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiXWZ0ACgkQOjLpvpq7dMqIbQCdFo9fjNejw9EOQbJuUqAxebtb
r/wAniUwwXjsAtf/sOVgarnr88gqXlTl
=mXRH
-----END PGP SIGNATURE-----