On Thu, May 23, 2024 at 12:58:27AM +0200, Paweł Bogusławski wrote: > Try to run > > git clone https://github.com/googleapis/google-api-go-client > > and limit interface speed somehow i.e. > > tc qdisc add dev eth0 root handle 1: htb default 12 > tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbps ceil 20kbps > tc qdisc add dev eth0 parent 1:12 netem delay 1000ms > > and after a while restore speed with i.e. > > tc qdisc del dev eth0 parent 1:12 netem delay 1000ms > > I tried this in Debian 11 and git 2.30.2 died with: > > error: 5723 bytes of body are still expected MiB | 920.00 KiB/s > fetch-pack: unexpected disconnect while reading sideband packet > fatal: early EOF > fatal: index-pack failed I did run it a few times. It usually succeeds, but sometimes fails. When it does fail, it does so in "slow" mode, without speeding back up. And I see one message from before your "error:" line, which is a report that curl reported that the connection dropped (curl is shuttling data back from the server in the form of "packet lines", each of which is prefixed with its expected size; the "N bytes of body are still expected" is just that parser seeing a truncated response from curl). But I don't think any of this is due to what Git is doing on the client side. From the client view, the server sends a TCP RST (which I observed with wireshark), and the connection drops. I'd suspect the drop is not even from the application level on the server side, but rather that something in the network path was mad about the delayed packets (or possibly the spam of duplicated TCP acks that I sometimes saw). So I really think this is a network issue, and not a Git issue in particular. It's possible that the networking stack that github.com uses is more picky about the things I mentioned above. But again, not a Git issue. -Peff
