threads / discuss / 27833

How to limit bandwidth used by git over SSH ?

Subject: How to limit bandwidth used by git over SSH ?

## tl;dr

4 messages between Jul 17, 2011 and Jul 20, 2011.

replies: 3people: 3as markdown or json

Ralph Seichter· Jul 17, 2011, 10:22 UTC · lore
Hello list,

I'm not really sure if this is a git or SSH issue, but I haven't figured out a solution yet. To transfer my data between two machines, I use

  git-push ssh://machineB.tld/foo/proj.git master

from machineA. Unfortunately, the machines are connected by a very low- bandwidth connection, which is completely choked by git-push. From what I've read so far, I guess this is the result of SSH setting TOS to "minimize delay", which prevents almost all other traffic during the push operation. Not good.

I haven't yet found a way of telling git (or SSH) to use no more than a given maximum bandwidth, like I could do with "scp -l {limit}". Did I miss something in the documentation?

Your help is appreciated.
-Ralph
Carlos Martín Nieto· Jul 19, 2011, 08:42 UTC · re: Ralph Seichter · lore

Re: How to limit bandwidth used by git over SSH ?

On Sun, 2011-07-17 at 12:22 +0200, Ralph Seichter wrote:
Show 12 quoted lines
> Hello list,
> 
> I'm not really sure if this is a git or SSH issue, but I haven't figured
> out a solution yet. To transfer my data between two machines, I use
> 
>   git-push ssh://machineB.tld/foo/proj.git master
> 
> from machineA. Unfortunately, the machines are connected by a very low-
> bandwidth connection, which is completely choked by git-push. From what
> I've read so far, I guess this is the result of SSH setting TOS to
> "minimize delay", which prevents almost all other traffic during the
> push operation. Not good.

A bit OT, but the situation where a link is chocked by a slow uplink getting filled is most likely due to buffer bloat on your modem/router which confuses TCP's congestion detection by buffering your packets too aggressively. But that's neither here nor there, I just wanted to point out it's not all ssh or git's fault.

> 
> I haven't yet found a way of telling git (or SSH) to use no more than a
> given maximum bandwidth, like I could do with "scp -l {limit}". Did I
> miss something in the documentation?

But coming back to SSH, scp knows it's going to do a file transfer, but git uses the ssh client to do a "normal" connection to a remote machine, to ssh, it's no different from a user typing really fast, which is probably why it's not supported out of the box.

There is a tool called trickle which takes over the network functions and can be used to limit upload and download speeds, so using it like

    trickle -u 20 git push ssh://machineB.tld/foo/proj.git master
should do the trick.
Cheers,
   cmn
Ralph Seichter· Jul 20, 2011, 19:18 UTC · re: Carlos Martín Nieto · lore

Re: How to limit bandwidth used by git over SSH ?

On 19.07.11 10:42, Carlos Martín Nieto wrote:
> There is a tool called trickle which takes over the network functions
> and can be used to limit upload and download speeds [...]

Thanks for the hint, Carlos. I tried to compile trickle on OS X 10.6.8, but without success. AFAIK, trickle has not been tested with OS X, and I am not even sure it trickle could work at all. Members of the MacPorts mailing list seem to confirm my suspicion. I've tried to contact the author of trickle; hopefully he will reply.

The general idea to use a tool besides git or SSH to shape the bandwidth usage seems valid, though.

-Ralph
Andreas Krey· Jul 20, 2011, 20:20 UTC · re: Ralph Seichter · lore

Re: How to limit bandwidth used by git over SSH ?

On Wed, 20 Jul 2011 21:18:56 +0000, Ralph Seichter wrote: ...

> The general idea to use a tool besides git or SSH to shape the bandwidth
> usage seems valid, though.

There are ways to integrate such a tool easier than the way trickle does; by using the 'ProxyCommand' configuration option of ssh, like 'ProxyCommand netcat $yourhost 22' or similar. Unfortunately, I don't know a suitable program offhand, netcat does not seem to have a bandwidth limiting option. But then such a beast is relatively easy to write.

Andreas
-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

← back to recent threads