If I do :

$ scp -l 1024 remote1:/path/to/file remote2:/path/to/destination

I can see, using nload on remote1, that the bandwidth used by scp isn't limited to 1024 kbits/s like I thought.

I found a workaround :

$ ssh remote1 'scp -l 1024 /path/to/file remote2:/path/to/destination'

But for the sake of knowledge, is it normal behavior that bandwidth limiting in my first command doesn't work ?

  • I've heard this may be system dependent. Perhaps give rsync --bwlimit a try (though it sounds like you're mostly curious about things). – B Layer Mar 3 '18 at 11:29
  • Ok thanks for that info. Yes it was out of curiosity, and also to be sure I didn't miss anything, I was just surprised when my SSH connection stalled despite of the "-l 1024" option. But if it's a system dependent feature that's fine by me (for those who want to know, it's Debian 9.3 / Kernel 4.13 / OpenSSH 7.4) . Anyway, my workaround works just fine, so no problem at all. – ChennyStar Mar 3 '18 at 13:49
  • Please don't treat hearsay in a comment as an answer. I just wanted to a) bring system-dependence up as a possibility and b) offer the rsync alternative. Regarding a) if you're using a modern, up-to-date linux distro it seems less likely (versus, say, Solaris or HP-UX or something). – B Layer Mar 3 '18 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.