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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
