>
> On May 3, 2010, at 11:52 PM, Trenton D. Adams wrote:
>> If I mount my usb key with "sync" option, I get 500kb or less transfer
>> speeds. If I use the gnome defaults, I get 60M+ for awhile, and then
>> it continually drops over time, down to the 500kb/s again. Gnome
>> defaults are...
>>
>> /dev/sdc1 on /media/FLASH type vfat
>> (rw,nosuid,nodev,noatime,uhelper=hal,shortname=lower,flush,uid=500)
>>
>> I have done similar tests on both Rally2 64G usb stick and sandisk
>> ultra (15M/s) SDHC 8G cards. I get lousy performance on both, unless
>> I set dirty bytes. These are both FAT 32. But, as you can see below,
>> 14 minutes to transfer less than a couple gigs is a little nutty. The
>> 3 minutes is a lot nicer. I am using 2.6.33 with a patch from
>>
https://bugzilla.kernel.org/show_bug.cgi?id=15374
>>
>> It really looks like there's a scheduling issue. It seems as if the
>> system is IO thrashing on the flash drive, and bounces all over the
>> place in terms of performance. Sometimes it's really low, like the
>> 2.73M/s, and other times it's really fast, like the 28.86M/s.
>> Although you can't see it there, there were times when rsync was
>> registering 200kb/s. None of them are "really" accurate, as
>> everything is queued for writing, but the final results of 1.5M/s
>> (calculated from the "real" time) is terrible.
>>
>> I have not seen this bad of performance on a normal USB drive, but
>> only on my USB flash drive, which is FAT32. In addition, Windows and
>> Mac systems transfer easily 9M/s write speeds on my rally 2.
>>
>> If I do the following...
>> echo 16000000 > /proc/sys/vm/dirty_bytes
>> the performance is 9-12M/s all the way through the transfer....
>
