MMC quirks relating to performance/lifetime.

[Arnd Bergmann]

On Saturday 12 February 2011 00:23:37 Linus Walleij wrote:
> H'm! That's an interesting resource indeed. When you write
> "From measurements, it appears that the size in which data is
> managed is typically 64 kb on SD cards" and "the size of the
> medium is always a multiple of entire allocation groups, and
> the most common size today is 4 MB" and then list
> Size, Allocation Unit, Write Size, Page Size, FAT Location,
> open AUs linear, open AUs random, Algorithm.
> 
> How exactly do you measure that?

It's not an exact science, but for most cards I have found
reasonably good ways to identify these numbers:

* the allocation unit size can almost always be found
  using read-only tests: reading 2kb across an allocation
  unit boundary is slightly slower than reading 2kb
  just before or just after the boundary.
  For a few cards where this doesn't work, I do write tests.
  After finding out how many allocation units can be open,
  it's trivial to find out the size.

* Finding the number of open allocation units means I write
  to the start of a few AUs alternating. Up to a certain
  number, the throughput is constant, above that, it drops
  sharply, sometimes by one or two orders of magnitude.

* The page size can also be found doing read-only tests, with
  varying block sizes. Smaller reads always give lower throughput
  than larger reads, but getting smaller than page size
  drops down significantly more than the difference between
  multi-page reads. This effect is more prominent in write tests.

* Finding the algorithm basically means I write an allocation
  unit using varying block sizes two times, using both linear
  access and random access. Cards that are optimized for
  linear access can be unbelievably slow in the random access
  tests. Sometimes the performance is the same above a specific
  block size, but slower for random access below that size.
  This is the write block size.

* Finding the write block size in cases where this is not the
  case can be harder. Most cards have a noticable performance
  drop in writes of less than a few pages, so that's the
  size I put in the table.

* The FAT location is clearly visible in a number of tests
  done inside of an allocation unit. It's normally slower for
  linear access, but faster for random access. Sometimes
  reading the FAT is also slower than reading elsewhere.

> I'm sort of smelling a card-probe.git with this tool that you
> can run on your device and get out data like that listed
> in your table. We have a rather large stash of cards we can
> probe for you to get that kind of data out if it is useful, and
> I believe other Linaro members may have such stuff too,
> if empirical data is usefult to your work.

The tool I'm using is on http://git.linaro.org/gitweb?p=people/arnd/flashbench.git
Unfortunately, it's not yet in the state that I'm recommending
anyone besides me to run it. I'm still rewriting the source
for every new card I get to nail down the specific properties.

I will make an announcement when I have the tool in a state
of general usefulness, and at that point I would really
appreciate people to run it, but just not yet.

	Arnd