-----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----- _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
