I'm really diggin' the two Sandisk 4GB SDHC I've got but only thing is bugging me:
The Expresscard multi-format card reader I have in my Macbook Pro won't recognize the SDHC cards but it plays just fine with all my other SD cards. I have to use a USB SDHC/SD adapter instead. Which while being fast as all get out isn't the "carry-fewer-things" style I'm looking for.
Stupid Belkin F5U213 Expresscard. No updated OS X "drivers" for it either.

Nice cheap SimpleTech "Bonzai" SDHC card reader, $13.82 from Amazon:
http://www.amazon.com/gp/product/B00...950383-7980817

Unlike the (more expensive) Sandisk MicroMate, the narrow "snout" on this device works well with the front mounted USB ports on my Antec Sonata II case, and with the crowded port layout on my trusty old Vaio Z505.

Edit: Even cheaper from Amazon's featured merchants - lowest price is currently $5.93 plus $4.99 shipping.

I came across interesting OLPC issue related to SD read speed, looks like the 12MB/s limit is not specific to N800 http://dev.laptop.org/ticket/397

Sorry to stray from the artificial benchmarks people have been batting about, but I decided to run a few symmetrical read/write tests relating to one of my own usage patterns. Specifically, I copied a 700MB set of MP3 files (equivalent to one well packed CD-R) to and from a collection of SD and SDHC cards, using both a USB-connected N800 and a SimpleTech Bonzai USB 2.0 card reader.

The host system is a homebrew Pentium D 820 (3.0 GHz) with Intel D945GNT motherboard, running XP SP2. The hard drive used for file transfers is a 10000 RPM, 74GB WD Raptor. The target cards were freshly formatted using Panasonic SDFormatter V2.0 with the default cluster size (16KB for the 1GB card, 32KB for the others) before each write test. Windows write caching was disabled, and all cards were written and ejected before the read tests were performed.

File transfers were initiated from the Windows Explorer GUI, timed with a handheld stopwatch, and reported below in minutes:seconds followed by the average transfer rate in MB/s.

Any rankings derived from this scenario are approximate, since the timings do vary across repeated runs. No attempt was made to average results over multiple tests.

Throughput becomes much lower with smaller average file sizes (such as maemo-mapper maps) and smaller cluster sizes (which store small files more efficiently). I haven't run the corresponding tests yet, but based on experience, the effect is substantial.

Presumably, memory card write performance could be improved by enabling Windows write caching on the removable volumes (Properties -> Hardware -> Policies -> Optimize for performance). However, I have not attempted to quantify this effect.

jpj:

Thanks for this comprehensive REAL WORLD speed test!

Based on the results the write speed seem to cap at about 2MB/sec, regardless of the card speed. In other words if buying SDHC cards going over Class 2 is waste of money. (Assuming the use is only with N800, AND future kernel updates do not enable faster transfer modes... )

I guess this is because FAT table needs to be updated more often with smaller clusters (after writing each cluster if write caching is not enabled).
Yes, if one cares to use safe device removal, it makes perfect sense to enable it. Write caching may improve speed and be much more friendly to the card, updating FAT table after each block write is not ideal.

Benchmarking with write cache enabled may give more realistic write speed numbers. Even now if the final speed is 2MB/s the real write speed is much higher (double?) since for each cluster you have FAT table write = one or more additional writes (I guess two writes: block list and file size attribute).

However this http://www.uwe-sieber.de/usbstick_e.html article claims enabling write caching does not help much unless you format the card with NTFS. It is hard to believe but with Microsoft everything is possible.

Slower card may result in even slower writes i.e. if the real writing speed is 2MB/s your visible speed may be below 1MB/s because of the FAT table updates.

Of course all this is just a theory, more benchmarks could prove me wrong.

Mara, I don't entirely agree. Some genius hacker might find a way around the bottleneck. Even if they don't, and you have no other SDHC devices (today or tomorrow), a USB card reader is still a cheap speedup for getting stuff onto the card. As you can see, it helps the writes (which suffer the most) much more than the reads.

fanoush, thanks for your comments and for the article link. I intend to run some comparative tests with small files, and will also investigate the effects of cluster size and write caching. Probably not with all cards at first, as the test matrix gets pretty large. But my curiosity is piqued, so I may as well carry on...

I was thinking that if I buy some SDHC cards I may as well format them as ext2 or ext3.. I have many SD-compatible devices but none of them are SDHC compatible (with the exception of the N800+new kernel). What happens to the card reader then? Is the filesystem (FAT) known by the card reader, or is that the responsibility of the OS (say, of my linux laptop)? This has never been entirely clear to me.. I would imagine the card reader would still work but a confirmation would be nice.

TA-t3, I couldn't resist firing up my Ubuntu/maemo VMWare Appliance for a quick test. File Browser shows an entry for Generic1 Card Reader1 but is "Unable to mount the selected volume" (FAT formatted ATP 1GB SD). The error detail says "could not execute pmount."

That's all I have time for right now.