SD / Filesystem write lags -- test?

Richard A. Smith richard at
Wed Jun 23 17:40:08 EDT 2010

On 06/23/2010 05:08 PM, Martin Langhoff wrote:

> Hi Quozl,
> you've mentioned some interesting details to our writes-to-SD-are-slow
> issues. Do we have a good scripted test that is current to the problem
> (as we understand it today)?
> I know a few things about linux's VFS tuning, and have some ideas I'd
> like to test...

What block size are we doing the write to the card in?   By tweaking the 
block size Mitch was able to achieve a pretty large speed up when 
writing the factory image under OFW.

Text of that tweaking below...

Inspired by some NANDblaster performance problems, I have been looking
at SD write timings as a function of transfer size.

The situation is complicated, but there are some glaring results that I
will point out, that are worth internalizing as rules of thumb.

Note that I have only tested one card so far, but I'm going out on a
limb and speculating that these results probably generalize.

a) There is a "sweet spot" at multiples of 16 KiB.  Writing 16 KiB is
faster than writing 8 KiB.  Similarly 32 KiB is faster than 24 KiB.
This probably means that the internal NAND page size times the number of
internal chips is 16 KiB, so multiples of 16 KiB can be done as just
write, rather than read-modify-write.

b) At multiples of 16 KiB, the usual-case write speed is roughly 10
MiB/sec (larger multiples are slightly faster, smaller multiples
slightly slower due to fixed overhead, but the effect is second-order.
The big win is the 16 KiB granularity effect.)

c) From time to time, a write will take substantially longer than the
good case.  2 mS of extra delay is fairly frequent, 10 to 30 mS is not
uncommon, 500 mS sometimes happens.

d) Writing 512 bytes takes about the same time (2 mS) as writing 16
KiB.  So for 512-byte writes, the effective speed is 125 KiB/sec.  I
recall some 40 MB SCSI-1 drives circa 1982 that went about that fast
(and without the delays as in (c)).

Based on this, I'm going to increase the write granularity in
NANDblaster from 2KiB to 16 KiB - at the expense of limiting the
worst-case NANDblastable .zd file size to 8 GB (for 1 G memory) / 4 GB
(for 512 M memory).  The .zd file is roughly half the size of the
populated portion of the OS image, so we would be able to NANDblast up
to about 16 G of OS image.

I recommend that we set the filesystem block size to 16 KiB.

Richard A. Smith  <richard at>
One Laptop per Child

More information about the Devel mailing list