Posting here to confirm that I have this same issue - If I blackhole a CDN it works for a while, until something happens (presuming server side) and then it breaks, and I have to do it again.
Only adding that I have better luck if I force myself to connect to another country to download. UK -> Netherlands.
Just to add, I do NOT have to do this on Windows. Its always at full speed on Windows. On Windows I connect to London or Manchester as my download servers and its full speed 99% of the time.
On Linux if I do that, my download speed is lucky to break 2MBs on my 2.5Gig up/down line. My ISP does not do any kind of traffic shaping.
I've also had the same issue for awhile now.
Both on Arch Linux and now the Steam Machine.
I ended up just blackholing both of the same exact IPs in my UDM Pro Max. Doing so and restarting the download brought me from 60mbps on the steam machine to about 400mbps. And on my Desktop I went from ~200mbps to nearly 2gbps.
I also have AT&T 5Gbps Fiber and was wondering if maybe this is a peering issue with AT&T or perhaps they are purposfully throttling certain CDNs. But if other people are having the same issue without AT&T then perhaps it's not that.
I've also had the same issue for awhile now. Both on Arch Linux and now the Steam Machine. I ended up just blackholing both of the same exact IPs in my UDM Pro Max. Doing so and restarting the download brought me from 60mbps on the steam machine to about 400mbps. And on my Desktop I went from ~200mbps to nearly 2gbps.
I also have AT&T 5Gbps Fiber and was wondering if maybe this is a peering issue with AT&T or perhaps they are purposfully throttling certain CDNs. But if other people are having the same issue without AT&T then perhaps it's not that.
I suspect it's not AT&T specific since another commentor doesn't live in the US. But very interesting that we have the same ISP situation and the same issue. Maybe isolated to AT&T in the states.
Same issue with me.
Confirming on AT&T in Fort Worth, TX (Linux Steam client 1785799196).
Download region was already US - Dallas (cell 65). Clearing cache and
steam_dev.cfg HTTP/2 tweaks did not help.
IContentServerDirectoryService/GetServersForSteamPipe?cell_id=65 returned
no Dallas SteamCache. Only:
cache1-sea1.steamcontent.com (Seattle, ~91% load) → 205.196.6.165 /2602:801:f00b:100::cdc4:6a5cache15-ord1.steamcontent.com (Chicago, ~95% load)Steam stayed on Seattle over IPv6 at ~45 Mbps. A Cloudflare download on
the same path did ~250–270 Mbps. After blackholing the Seattle addresses
and pausing/resuming, Steam logged 27 chunk failures, dropped SteamCache
priority class 5, and opened Fastly/Akamai/Google. Rate jumped to
~230–320 Mbps.
Root cause looks like Steam preferring a reachable-but-slow SteamCache and
never failing over to CDN while that host still answers. Changing region
cannot help when Dallas has no local cache in the directory.
I'm experiencing this same issue on arch. speeds fluctuate from 1.3gbps down to 200mbps with a VPN on, barely hits 150mbps without a VPN. Works fine on Windows with no VPN. Should be getting 3gbps+.
Nothing extracted yet.
Your system information
ixgbeProblem
Steam downloads on Linux are much slower than expected. On my normal AT&T route, Steam usually downloads around 100 to 350 Mbps, despite having a 5Gb connection and a 10GbE NIC. The same system can do much faster speeds outside Steam, and the NIC is linked correctly at 10Gbps full duplex.
Steam is not CPU or disk bottlenecked. During downloads,
pidstatdid not show Steam maxing out the CPU, and the system is using a fast NVMe drive.Network/NIC verification
Linux detects the active NIC correctly:
Things I tried that did not fix it
steam_dev.cfgdnsmasqcachingethtoolpidstatKey finding
Using a VPN immediately raised Steam downloads to around 900 Mbps, which appears to be the VPN throughput limit.
The major difference was the number and selection of Steam CDN endpoints.
Without VPN, Steam heavily favored these two Valve CDN IPs:
Example without VPN:
With VPN, Steam opened many more CDN connections across more Valve cache nodes:
Workaround
I blackholed the two slow CDN IPs locally:
After doing this, Steam selected different CDN endpoints:
Download speed improved to around 1.9 Gbps.
Command used to inspect Steam CDN IPs
MTR observations
Off VPN, MTR to the final Valve CDN destinations showed 0% loss. So this does not look like simple packet loss.
Example final destinations:
Conclusion
This appears to be a Steam CDN selection/fanout issue or a route specific CDN assignment problem. On my normal AT&T route, Steam heavily favors a small number of slow Valve CDN IPs. When those IPs are blocked, or when I use a VPN, Steam selects a broader/faster set of CDN endpoints and download speed improves dramatically.
The workaround is not ideal because users should not need to manually blackhole CDN IPs. It would be helpful if Steam could detect poor CDN throughput and rotate away from underperforming cache nodes more aggressively.