Follow-up Comment #1, sr #110712 (project administration):
Sorry I didn't respond sooner. I read your report. But I couldn't
think of any reason why things might be very slow for you. This is my
first chance to post that I am sorry but I don't have a clue. It
works for me and I can clone and push to repositories and things are
fast for me.
rwp@angst:/tmp/junk$ time git clone
git.savannah.gnu.org:/srv/git/emacs/org-mode.git
Cloning into 'org-mode'...
remote: Counting objects: 135896, done.
remote: Compressing objects: 100% (29366/29366), done.
remote: Total 135896 (delta 106451), reused 135807 (delta 106390)
Receiving objects: 100% (135896/135896), 88.42 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (106451/106451), done.
real 1m2.819s
user 0m58.152s
sys 0m2.361s
rwp@angst:/tmp/junk$ cd org-mode
bob@hysteria:/tmp/junk/org-mode$ time git pull
Already up to date.
real 0m4.458s
user 0m0.203s
sys 0m0.022s
I am in Colorado so this has to work across the country. I do have a
fast home connection on a fiber network. (Finally!) But it is a good
test across the country and across the Internet router connections.
> debug1: /home/tec/.ssh/config line 81: Applying options for *
> debug1: /usr/etc/ssh/ssh_config line 27: Applying options for *
What options are being applied there? They might be incompatible.
> debug1: auto-mux: Trying existing master
> debug1: multiplexing control connection
> debug2: fd 13 setting O_NONBLOCK
> debug3: fd 13 is O_NONBLOCK
> debug1: channel 5: new [mux-control]
> debug3: channel_post_mux_listener: new mux channel 5 fd 13
> debug3: mux_master_read_cb: channel 5: hello sent
> debug3: mux_master_read_cb: channel 5 packet type 0x00000001 len 4
> debug2: mux_master_process_hello: channel 5 client version 4
> debug3: mux_master_read_cb: channel 5 packet type 0x10000004 len 4
> debug2: mux_master_process_alive_check: channel 5: alive check
> debug3: mux_master_read_cb: channel 5 packet type 0x10000002 len 70
> debug2: mux_master_process_new_session: channel 5: request tty 1, X 0, agent
0, subsys 0, term "xterm-256color", cmd "", env 1
> debug3: mux_master_process_new_session: got fds stdin 14, stdout 15, stderr
16
> debug1: channel 6: new [client-session]
> debug2: mux_master_process_new_session: channel_new: 6 linked to control
channel 5
> debug2: channel 6: send open
> debug3: send packet: type 90
This looks like your configuration is trying to use a ControlMaster to
reuse a previous connection. That can't work. And, I don't know, but
it feels suspicious that this might be part of the problem. I suggest
removing any ControlMaster configuration for Savannah as that requires
both a persistent connection and auxiliary ports both of which are
restricted.
I believe you can configure ssh to avoid specific sites. For example
I am pretty sure (needs to be tested) that one can specify a host
section this way and avoid having it take effect for the negated
pattern.
Host * !*.gnu.org
And that is all I can think of at the moment. No one else is
reporting unusuably slow data transfer. Therefore it seems the
problem is most likely on your end of the connection. In which case
only you on your end can debug it.
I am happy to help in the debugging in any way possible. Let me know
how I can help.
_______________________________________________________
Reply to this item at:
<https://savannah.nongnu.org/support/?110712>
_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/
