-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Thu, Jul 24, 2008 at 08:49, Andy Green <[EMAIL PROTECTED]> wrote: |> Well, a good rule of thumb for generic 1-bit transfer is divide by 10 |> for the max speed in Bytes/sec you could expect, here we have 4-bit so |> the peak raw trasfer speed is ~10MBytes/sec *BUT* after Glamo pulls the |> data from the card, we have to sit there dragging it into the CPU |> memory, on top of card latencies and command setup the speed is way |> slower, still a decent ~2MBytes/sec each way IIRC. |> |> - -Andy | | | Thanks. | | This is something I also wanted to know for the choice of a new card. | | So we may say that up to 10MBytes/s, max speed of the microSD matters. | After it should not much. (?) | (and looks like 10Mbytes/s is currently what offer rather high end microSD)
The MCI / MMC stack in Linux negotiates the clock speed with the card, all the microSD cards I saw say they can handle 16MHz and that's what they get. We can't sustain the actual throughput that implies right now, although soon we might be able to get a little better in the driver. | One more question though : if the card is slow, throughput will be | lower, but will the CPU / glamo graphic bus be able to benefit of more | resources while the card transfer occur ? | Or does it just had to time to wait and CPU / glamo bus are as much | busy (or waiting) ? Have to make clear what we mean by "slow", it means latency to NAND inside card as I understand it. So every time you ask for some data it is slower to start sending it and chokes more often waiting on getting next block from NAND. ---> | Same question if we lower the SD clock rate. Is it equivalent to | having a slower card ? If it's slow at the card it will block Glamo memory less (probably... arbitrator in Glamo might mess that assumption up) and definitely block the CPU bus less. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiJrHgACgkQOjLpvpq7dMqLWwCfUyta7nEdXK5JXOdEkMYAoJBz 5dMAoJPdUCGq0xBpbDRCoDLp2wkR6EOT =k1zT -----END PGP SIGNATURE----- _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community