Filesystem transfer speeds "rubberband"
 

I'm experiencing an issue, and I may have been experiencing this issue the entire time that I've been on Linux, (since 2010), but it's only been thrown in my face recently when I switched to Linux Mint KDE edition, and have watched the transfer dialog for Dolphin, which provides some very interesting information.

Transfers between drives local to the computer, which has both internal SATA, and USB 2 drives connected, and transfers via sshfs (basically, it affects all protocols) all share a "rubberband" effect.

Wherein the files to be copied or moved are first read at the maximum speed of the source drive, without any noticeable activity either via HDD LED, or via iotop to the desination drive, up to some arbitrary amount (which is usually greater than a GB), and then reading from the source nearly stops, (from 50MB/s down to tens of KB/s, as an example, for sshfs transfers), until the write cache has been purged, and then it repeats. This has the obvious negative effect of reducing transfers to about half-speed, with the graph appearing saw-toothed.

This occurs with Dolphin, of course, PCManFM, cp, and any other file manager I've used. My testing has revealed it occurs in Mint, Fedora, and Ubuntu in equal measure, so I can only suspect that it has to do with the kernel write caching for drives, but I can't seem to find any information about it as distinguished from the on-board cache that all HDDs have.

So is there a way to preferably control, or if necessary disable the kernel write-caching, perhaps in real time?

No, you can't disable the page cache (which handles both read and write). It can be bypassed if the application is capable of direct I/O.
What you are seeing is more related to the I/O scheduler in use. As all operating systems are a compromise between the demands of all users, I/O are generally delayed so that (later) I/O to the same area are consolidated so the heads on the drive aren't thrashing all over the place. This makes the average "better", but not maybe for all I/O's when looked at individually. And reads are generally preferenced over writes as (interactive) users have to wait for reads to complete.
You can see what you're currently using viaYou can (as root) also use echo to change the scheduler for each device individually. There are also tunable in /sys/block/<device>/queue/iosched - change them at your own risk.

Lots of articles on the web that may help.

usb2 drives will be dead slow
it can only read OR wright , only one thing at a time and at 64 mbs
but with lagre files the speed WILL drop to 12 or so meg/s
the nature of usb2

if possible upgrade hardware to usb3

I'll assume you meant small files, as large files should go faster on any hardware, due to sequential access.

And when dealing with laptop drives running at 5200 RPM, which can only beat USB2 by a factor of 2.5, it doesn't quite seem "dead slow". :)

First make sure you have the USB_EHCI_TT_NEWSCHED [=y] (Improved Transaction Translator scheduling) kernel option enabled. This can greatly speed up transfers using USB 2.0.

Also remember that USB transfers data in bursts, so I don't see anything particularly unusual about this transfer pattern.

Upgrading to USB 3.0 is a good idea, but may be expensive depending on whether your system supports it or not.

Also, there is no great risk in changing the I/O scheduler on the fly. Changing it to 'deadline' may help in some cases.

Serious deja-vu there, for some reason. Maybe I'd looked this up in the past, I don't know. Either way, the effect of setting all drives being transferred to/from to "cfq" is that now the transfer speeds are more of a straight line. Thanks for the tip. :D

Is that something that can be toggled without compiling the kernel? (I'm afraid my attempts to compile a kernel have thus far met with little success)

I've never heard that before, but 'CFQ' did smooth out the pattern a lot, and raised the average speed to almost what the drive is capable of in benchmarking. I should point out that both drives were on 'deadline', and were having this problem.

It's a laptop without 3.0, which I'm going to replace in the future anyway. I'll likely buy internal drives for the desktop I'm building, rather than relying on external storage.

Yes it is a kernel config option. If you can't compile a kernel then just leave it. You can see if the option is set by checking the kernel config. It is often found at '/boot/config' or '/proc/config.gz'.

Member Response
 

Hi,

Gnu/Linux distributions sometimes select the 'cfq' scheduler as the default while yours seems to use 'deadline'. You can easily find out which scheduler your device(s) use. Most setup a system wide scheduler. You can setup each device to use a specific scheduler. This is easily done safely. This is how my 'sda' 'SSD' device is configured.
Look at LQ post #26 to see how this can be done. I use Slackware and the default scheduler is 'cfq' for the system. Personally I tune for each device to get the best out of the device for the system. 'noop' is a 'FIFO' scheduler and best suited for my 'SSD' hardware which utilizes a 'SandForce' controller so the 'SSD' is not waiting.. I can optimize the system since 'TRIM' is supported. Plus the device does support 'write-back cache' so that too is enabled to enhance write(s).

Look at 'Best practice: I/O schedulers' from IBM white paper for a good definition for schedulers;Solid State Drives - ArchWiki is very informational for 'SSD' setup.
Additional links that you may find to be useful;
One note of caution: You should be careful not to mix setup information for older vs newer 'SSD' since you can produce some unwanted situations.