git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Cloning does not work on available download bandwidth changes

From
Jeff King <peff@peff.net>
Date
May 23, 2024, 09:04 UTC
Message-ID
<20240523090419.GB1306938@coredump.intra.peff.net>
In-Reply-To
<293afb32-99b1-4562-b339-7862698ef00f@ib.pl>
On Thu, May 23, 2024 at 12:58:27AM +0200, Paweł Bogusławski wrote:
Show 20 quoted lines
> 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
Previous: Paweł BogusławskiNext: Paweł Bogusławski
Message 4 of 6 in “Cloning does not work on available download bandwidth changes”
  1. Paweł BogusławskiMay 22, 2024
  2. brian m. carlsonMay 22, 2024
  3. Paweł BogusławskiMay 22, 2024
  4. Jeff KingMay 23, 2024
  5. Paweł BogusławskiMay 23, 2024
  6. rsbecker@nexbridge.comMay 23, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.