Make transferring files under dropbear MUCH faster

Imagine you need to transfer a bunch of files from one box to another, and you don't want to do it in plain sight because why would you? So, you'll very simply copy files under SSH, using scp or rsync or whatever you want.

You start the operation and notice how it goes at around 760 KiB/s. Which isn't exactly slow per-se, but it also isn't that fast. Especially considering you're transferring files from two servers which outta have some much faster interfaces available.

What gives ?

Pondering this very question, I suspected something was wrong but I wasn't sure what & why. So I quickly dd-ed some random data so I could test an encryption-free transfer and behold: we're bursting at over 100 MiB/s !

Right, we're talking more than 2 orders of magnitude of differences here. Granted that's burst speed and the average over long enough amount of data would be lower, but it would still be a fat order of magnitude faster, to say the least.

So the network can handle the speeds, could it be the encryption that somehow slows down immensely the operation ? And because I'm using dropbear as SSH server, I find myself wondering if it might not be the cause. (Mainly because I haven't seen such slowdowns before using openssh, though admittedly if was using different servers/networks.)

Obviously I installed openssh to see how things fare under its banner, and indeed I then got what I'll call "normal" speeds, that is expected speeds given the network interfaces used.

Hey now, little speedy head...

After some more investigating, it turned out that indeed because dropbear is intended as a small & lightweight server, notably used in embedded scenario where CPU & RAM resources might be scarce, it uses default configuration reflecting such cases.

One of these settings is the window size of the buffer used to transmit data, which defaults to a mere 24 576 (24 KiB), aka a tiny one.

It's a know fact, so much so that there's even a command-line option to set it to a different value, as its help screen will tell you :

-W <receive_window_buffer> (default 24576, larger may be faster, max 10MB)

And yes, that hint is very likely to be true : larger may be faster. In my case after running a few quick tries I settled for 6,291,456 (6 MiB) and voilà: data rushes from one box to the other reaching more than 100 MiB/s !

So there you go, in case you find yourself noticing slow speeds under dropbear there might be an easy fix.

(Granted I haven't actually looked how much memory usage grew because of such a change, because in my case there is memory available so why not use it.)