Re: Writing to USB3 memory stick with 4.4 is 52 times slower than Win7 inside virtualbox

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 3 Feb 2016, Marc MERLIN wrote:

> On Wed, Feb 03, 2016 at 09:05:26PM -0800, Greg Kroah-Hartman wrote:
> > > Still, you're likely on the right track, something seems to wait for
> > > each write to proceed before sending the next one.
> > 
> > What are you using to copy files?
>  
> midnight commander, or straight cp, only copying one big file, seeing
> how quickly it's being copied.
> 
> > > Is there another option I can try?
> > 
> > Turning off sync is the key thing here, without that on, things "seem"
> > to be faster now.  The real speed is the same, writes for your device
> 
> And by faster, it's actually instant as long as the file is smaller than
> my amount of free RAM :)

The sync option really slows things down a lot.  That's why you were 
originally seeing such slow transfers under Linux.

> > is slow due to the flash chip, not the USB bandwidth.  I'd try a "real"
> 
> True, but it's not that simple. My USB stick actually has a red LED that
> flashes when it's working.
> When I copy with windows at 20MB/s+, the USB LED stops flashing when
> windows says the copy is over, and I can safely eject hardware.
> 
> With linux, I tried this:
> bash -c 'time cp /var/local/space/vid/300MB* /mnt/mnt; umount /mnt/mnt'
> Sadly, it returns 2s for both, meaning that unmount succeeds before the
> data is on the stick.

That command will time the cp but not the umount.  You should have 
done:

time bash -c 'cp /var/local/space/vid/300MB* /mnt/mnt ; umount /mnt/mnt'

to time both the copy and the following unmount.

Incidentally, did you do this test within VirtualBox (to match the
Windows test) or running on the bare hardware?

> If I watch the flashing LED, the copy takes around 15 seconds. This
> means my copy speed under linux was about 73MB/s now, but that's based
> on an LED flashing.

Still, it's a more appropriate value, indicating that the actual 
transfer speed is reasonably close to what it should be.

> > filesystem benchmark tool if you really want to know the speeds it can
> > work at (fio is good.)
> 
> There are plenty of FS benchmarks, if you have one specific one with
> specific options you'd like me to use, I'm happy to.
> 
> But really a copy of a 300MB file sequentially is the only test I really
> care about and that's trivial to reproduce without more complex
> benchmark tools.
> 
> If I had to guess, sync causes cp(1) to be very conservative and wait
> for a sync after each 4KB block while windows probably blasts all the
> data with fewer sync calls in between?
> (wild guess at this point)

Probably something like that.  It doesn't actually change the behavior 
of the cp program; it changes the behavior of the kernel's filesystem 
layer.  The end effect is the same, though.

> But the main point remains that default mount options and default cp
> work at horrible speed.

That's a new main point.  Your original main point was that write 
transfers under Linux were horribly slow.  You now know this was due to 
the sync option, not any fault in the USB driver stack.

The default mount options are a question for another mailing list; they 
have nothing at all to do with USB.

> I'm happy to try stuff to get around that
> (nosync might be one, but having my stick write after I unmounted it,
> makes me very nervous), so I'd love a solution where cp succeeds when
> the data has been synced to flash, and at the very least for unmount not
> to return before the data has been committed.

cp generally does not wait for data to be written (as far as I know).  
umount, on the other hand, _is_ supposed to wait.  If it doesn't then 
it's a bug in umount, not a bug in the USB stack.  Are you certain that 
umount doesn't wait for all the data to be transferred?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux