Mailing List Archive

limiting SSH client's bandwidth?
Is it somehow possible to limit OpenSSH client's bandwidth?

Today I was copying data (whole block devices) over internet
with:

dd if=/dev/san10/xen1 | bzip2 -9 | ssh 192.168.15.46 "bzip2 -d | dd of=/dev/san18/xen1"


It worked fine, but the latency of other connections was horrible,
because the above connection ate almost all bandwidth available.


scp has this option:

-l limit
Limits the used bandwidth, specified in Kbit/s.

But it looks that it's not available to ssh.

I wouldn't like to use 3rd party programs or system settings,
because they are not portable, sometimes require root privileges
and are just additional burden for a one-off task.


--
Tomasz Chmielewski
http://wpkg.org
Re: limiting SSH client's bandwidth? [ In reply to ]
Maybe look into Trickle?

http://www.linux.com/feature/61293

Cheers,
--scm

On Thu, Feb 12, 2009 at 6:40 AM, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> Is it somehow possible to limit OpenSSH client's bandwidth?
Re: limiting SSH client's bandwidth? [ In reply to ]
Shawn Merdinger schrieb:
> Maybe look into Trickle?
>
> http://www.linux.com/feature/61293

I know trickle, but such methods (iptables, trickle, CFQ/HTB, etc.) are
just not portable - require root privileges, need a compiler (think of
/home mounted with noexec), won't work on some systems (i.e. Windows).

So, "a simple way", it's just not possible today.

Has someone though before of adding "-l (limit)" flag from scp also to ssh?


--
Tomasz Chmielewski
http://wpkg.org
Re: limiting SSH client's bandwidth? [ In reply to ]
Tomasz Chmielewski wrote:
> Is it somehow possible to limit OpenSSH client's bandwidth?
>
> Today I was copying data (whole block devices) over internet
> with:
>
> dd if=/dev/san10/xen1 | bzip2 -9 | ssh 192.168.15.46 "bzip2 -d | dd of=/dev/san18/xen1"
>
>
> It worked fine, but the latency of other connections was horrible,
> because the above connection ate almost all bandwidth available.
>
>
> scp has this option:
>
> -l limit
> Limits the used bandwidth, specified in Kbit/s.
>
> But it looks that it's not available to ssh.
>
> I wouldn't like to use 3rd party programs or system settings,
> because they are not portable, sometimes require root privileges
> and are just additional burden for a one-off task.
>

You can also look at the pv command, take a look at man pv it has a
very nice limiting function build for these kind of things.

Best regards,

Jelle
Re: limiting SSH client's bandwidth? [ In reply to ]
On Thu, 2009-02-12 at 12:40 +0100, Tomasz Chmielewski wrote:
> Is it somehow possible to limit OpenSSH client's bandwidth?
>
> Today I was copying data (whole block devices) over internet
> with:
>
> dd if=/dev/san10/xen1 | bzip2 -9 | ssh 192.168.15.46 "bzip2 -d | dd of=/dev/san18/xen1"
>
>
> It worked fine, but the latency of other connections was horrible,
> because the above connection ate almost all bandwidth available.
>
>
> scp has this option:
>
> -l limit
> Limits the used bandwidth, specified in Kbit/s.
>
> But it looks that it's not available to ssh.
>
> I wouldn't like to use 3rd party programs or system settings,
> because they are not portable, sometimes require root privileges
> and are just additional burden for a one-off task.
>
>

SSH has always been meant for interactive shell - not file copying.
therefore, the -l (or similar) flag has no point there (unless your are
piping file copy operations through SSH) :D

Other problem is that SSH (being meant for interactive shell) sets the
TOS (type of service) bits to 'minimize delay'. SCP on contrary does not
do this, so even not throttled scp (full bandwidth) won't spoil your
concurrent ssh interactivity, because default qdisc attached to each
device on linux - pfifo_fast honours TOS bits - will send out SSH
traffic first, let the scp traffic queue.

M.



This e-mail message may contain confidential and/or privileged information. If you are not an addressee or otherwise authorized to receive this message, you should not use, copy, disclose or take any action based on this e-mail or any information contained in the message.
If you have received this material in error, please advise the sender immediately by reply e-mail and delete this message. Thank you.
Allinea Software and Streamline Computing are trading divisions of Concurrent Thinking Limited: Registered in England and Wales No: 03913912
Registered Address: The Innovation Centre, Warwick Technology Park, Gallows Hill, Warwick, CV34 6UW, United Kingdom