Date:	Mon, 3 May 2010 21:52:44 -0600
From:	"Trenton D. Adams" <trenton.d.adams@...il.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Flash IO slow 1.5 MB/s

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

As an example, checkout this rsync
time rsync -v --progress /home/share/*.avi /media/disk/
1.avi
   709911016 100%    8.88MB/s    0:01:16 (xfer#1, to-check=1/2)
2.avi
   621254748 100%    8.07MB/s    0:01:13 (xfer#2, to-check=0/2)

sent 1331328404 bytes  received 50 bytes  1510298.87 bytes/sec
total size is 1331165764  speedup is 1.00

real    14m40.863s
user    0m8.473s
sys     0m9.525s

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.  It is
also interesting to note that it hung for 2-5 seconds in the middle,
and then continued, for whatever reason.  Perhaps it was waiting for a
response from the flash drive.  Anyhow, I don't like this solution,
because it affects the entire system.  And, it's really nice to have
100M+/s on the local disks, at times when I'm writing 50-500M and I'm
done.

Now check out this rsync, with the dirty_bytes set.  I see a VERY
consistent transfer speed, which may be "marginally" slower than Mac
or Windows, but I'd have to test to be sure.

tdanotebook sync # time rsync -v --progress /home/share/*.avi /media/disk/
1.avi
   709911016 100%    7.16MB/s    0:01:34 (xfer#1, to-check=1/2)
2.avi
   621254748 100%    7.58MB/s    0:01:18 (xfer#2, to-check=0/2)

sent 1331328404 bytes  received 50 bytes  7673362.85 bytes/sec
total size is 1331165764  speedup is 1.00

real    2m53.456s
user    0m8.325s
sys     0m9.453s

I'm wondering if there's a way of having flash drives default to
dirty_bytes of 16M or less, and all other IO devices use normal
default values?  Perhaps it could become a mount option, or
configurable through /proc or sysctl?  Or, is there a way of improving
"sync" option for these devices, seeing that's what they really should
be.  Windows/Mac have them in "sync" mode, or at least a semi-sync
mode, by default.  Does sync mode just default to 512 byte blocks, and
that's why it's sooo slow?

Or, it may be nice for the system to automatically match the
dirty_bytes to the actual speed of the physical device, adjusting it
dynamically upward until it matches the transfer MB/s.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists