tcp-brutal

There's an open source implementation that does something similar but for a more specific use case: https://github.com/apernet/tcp-brutal There's gotta be a less antisocial way though. I'd say using BBR and increasing the buffer sizes to 64 MiB does the trick in most cases.

At this point escalating, or threatening to, might be the better option. But I can't help trying to figure out how to solve a people/organizational problem with a technological solution. Github is still famously IPv4 only. I don't know if there is a split between the SSH (if you use SSH to access the repos) and HTTPS (the tarballs) setup on their end, so maybe you get full speed on IPv6 and limited on IPv4 (or the other way around). Try disabling IPv6 on your end, if the speeds match then this might be it. If IPv6 is fast using an IPv4 gateway that tunnels via an IPv6 VPN might be a workaround. I also had a similar problem a while back. Some speedtests showed more bandwidth than I could get in regular HTTPS downloads. I could get multiple downloads running at the same time that in total added up to the expected speed. In my case the line

https://github.com/apernet/hysteria has the option to use https://github.com/apernet/tcp-brutal, a deliberately unfair/selfish congestion control algorithm. It's designed to mitigate certain methods of blocking-via-throttling. I looked into it for a report I wrote a while back, and I was surprised to find that nobody has made something purpose-built for greedy TCP congestion handling in order to improve performance at the expense of others. If there is such a thing, I couldn't find it. Perhaps I'm a little too cynical in my expectations! Maybe TCP-over-TCP is so bad that it's not worth it?