Seeing as everyone in here has a lot of bad experiences with ISPs, should I straight up skip attempting to talk with them at all and go for an FCC complaint/government complaint?
Seeing as everyone in here has a lot of bad experiences with ISPs, should I straight up skip attempting to talk with them at all and go for an FCC complaint/government complaint?
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 was just lossy enough (TCP retransmits in Wireshark) for TCP to never scale up its window size properly beyond a certain limit per connection. I verified this by running iperf in TCP and UDP against a gigabit server, UDP reached near full speed because it didn't care about a few lost packages. Working around that issue might be a bit harder, maybe [1] via [2] can provide some ideas to look into.
Yes, this is behavior I am seeing on my end too. On Arch Linux, I enabled parallel downloads for updates via pacman. Whenever updating my system, I can saturate my connection, but as soon as I get down to one huge package, like wallpapers or rocm-llvm, the download speed for that package is only 8 MB/s.
Considering the fact that I get full speeds everywhere whenever I'm using a VPN, am I right to assume that there is an issue with AT&T's internal routing? And, that issue doesn't effect every path? I'm not really an expert at doing networking stuff, but I wanna gather as much empirical data to construct a report and do statistical tests n stuff.
Perhaps the VPN you use is on a protocol/port that isn't outright rate-limited and since ATT can't peak inside your tunnel to see what you are doing with the bandwidth, it avoids any QoS/shaping/limiting that your non-VPN connection is subjected to.
Take some pcaps of downloads that don't work. See if there's some common thing going on. Are you getting packets slowly with minimal loss or are there many missing packets? Does it seem like a path MTU issue [1]? Is the RTT reasonable?
Traceroutes from your side aren't the most helpful, but see what's the same and different between download IPs that work well and those that don't. If we assume congestion is from the internet to you, traceroutes from the download servers that don't work would be most useful, but that's hard to get. Sometimes you can find a hosting provider with test download urls and a looking glass, which can be pretty helpful if that's what you're experiencing.
Definitely look at ipv4 and ipv6. It's pretty common to get different routing between the same two endpoints on v4 and v6, so you get more debugging.
If it is a routing problem, be sure you're testing same IPs for download between native and VPN, if you download by hostname and the DNS resolves differently, try both IPs both ways... maybe you're just getting poor selection from DNS which can be addressed in different wayss. If your native DNS always gives you cross country servers and your VPN is local and gets local servers, there you go.
But if you do figure out the problem, you also need to find a way to escalate. Chances are phone support isn't going to be super helpful. Explore reddit to see if people get results there, find out what the replacement for dslreports is, etc.
Edit to add: when you do reach out, you want to share a concise summary and easy to repeat test; not so much all the research you did behind it. But ... that test should include multiple sources for the download or support will say it's a single site issue and close the ticket.
[1] I always blame PMTU, what does my test here show http://pmtud.enslaves.us/ If you don't get OK in all the boxes, that could be part of the problem... But that's usually slow start, not slow throughput after starting.