Very slow git clone

Site Feedback and Other Questions
1

I am in the Philippines, on the fiber ISP named "Globe". I tried to use OpenWrt SDK today, and it failed due to network timeouts:

[aep@aep-haswell openwrt-sdk-24.10.1-mediatek-filogic_gcc-13.3.0_musl.Linux-x86_64]$ ./scripts/feeds update
Updating feed 'base' from 'https://git.openwrt.org/openwrt/openwrt.git;openwrt-24.10' ...
Cloning into './feeds/base'...
remote: Enumerating objects: 27561, done.
remote: Counting objects: 100% (27561/27561), done.
remote: Compressing objects: 100% (12838/12838), done.
error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
failed.
Updating feed 'packages' from 'https://git.openwrt.org/feed/packages.git^d8cd30f4e281d6853b3de134c4f147a807583e43' ...
Cloning into './feeds/packages'...
remote: Enumerating objects: 7349, done.
remote: Counting objects: 100% (7349/7349), done.
remote: Compressing objects: 100% (6028/6028), done.
error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
failed.
...

While git was doing its download job, the speed was oscillating between 10 KB/s and 1 MB/s, mostly staying on the low side.

I know that the server is in Germany, so quite far, and the networks between the two countries are quite lossy.

Dear infra admins: The situation can possibly be improved by switching the TCP congestion control algorithm to BBR on the servers. Could you please do it, unless it's already set up this way or there are reasons not to?

$ cat /etc/sysctl.d/99-bbr.conf 
net.ipv4.tcp_congestion_control=bbr

Here is my old blog post regarding this optimization: https://patrakov.blogspot.com/2018/02/a-case-of-network-throughput.html

2

Heh, but that would not close open connection...

3

Current non-event-based HTTP servers enforce a minimum transfer speed in order to mitigate the Slow Loris attack. So "a few seconds with zero bytes transferred" would be a good reason to close the connection server-side abruptly.

Besides, the complaint here is that, before the close, the connection struggled to keep even 10 KB/s transferred.

Although, on a second thought, the observed behavior is also consistent with a memory overuse by something else running on the same server + OOM.

4

Try git config core.compression 1 might jump over timeouts or server load (not involved with project's servers, just a blind guess from symptoms)

5

Probably won't help...

BBR can be single ended, so enabling on your end also works...

6

According to Google presentations of that time, it needs to be enabled on the sender size.

7

BBR won't solve the problem...

This is more of a CDN issue - there's options here I suppose...