Hi Kai, Thanks for your help :-)
Code here: /usr/share/info $ cat /proc/sys/net/ipv4/tcp_fastopen 1 /usr/share/info $ cat /proc/sys/net/core/default_qdisc pfifo_fast /usr/share/info $ cat /proc/sys/net/ipv4/tcp_congestion_control cubic dnsmasq may help because...if my understanding is correct, Steam Linux client has a bug that it tries to query the DNS too often during downloading, then its request got throttled. Please see https://wiki.gentoo.org/wiki/Steam/Client_troubleshooting Section "Slow download speeds". For disk, I don't think it fits my case because for a downloading speed of 100KB/s, disk write should not be a bottleneck. I suspect it is related to Linux client because Steam Windows client on my machine downloads at the normal speed... Well, I am not that familiar with network tuning things...so I will definitely check the methods you mentioned. Thanks, Danny On 2017-03-15 21:07, Kai Krakow <hurikha...@gmail.com> wrote: > Am Wed, 15 Mar 2017 21:53:44 +0100 > schrieb Kai Krakow <hurikha...@gmail.com>: > >> Am Wed, 15 Mar 2017 21:24:10 +0800 >> schrieb Danny YUE <sheepd...@gmail.com>: >> >> > Hi guys, >> > >> > I just got Steam installed and running successfully on my machine, >> > and tried to get CS:GO running smoothly, which made me really >> > happy :-D >> > >> > However when Steam is downloading games, the speed is extremely >> > slow, down to several KB/s, even some bytes/s. >> > I have already installed dnsmasq and it *was* good during >> > downloading CS:GO (~4MB/s), but became slow again with Civilization >> > V. >> > >> > I googled a lot but all point to installing dnsmasq, which I don't >> > think is really helpful since I already have done that... >> > >> > Also I'm sure downloading region is correct. >> > >> > Anybody experienced the same issue with dnsmasq installed? >> > Any clue is welcome and thanks in advance. >> >> Here, it's downloading with peak bandwidths of 48 mbytes/s but usually >> it's around 38 mbytes/s. However, I sometimes see slowdowns, too. I >> guess that games are downloaded file by file, and when a lot of small >> files are left in the queue, it just cannot get good bandwidth. >> >> But I only see such slowdowns mostly short before the last few >> megabytes of a game. >> >> Could you check if your downloaded games consist of many smallish >> files? Then that could be the explanation. >> >> You could try activating fq_codel and tcp fastopen: >> >> In /proc/sys/net/ipv4/tcp_fastopen it should say 1. >> In /proc/sys/net/core/default_qdisc it should say fq_codel. >> >> Also, you may want to try out bbr congestion control: >> >> In /proc/sys/net/ipv4/tcp_congestion_control it should say bbr. >> >> By recompiling the kernel, you can reconfigure the defaults for this >> (and enable support). Some of these need modern kernels. >> >> Additionally, many small tcp request need a good portion of your >> upload bandwidth and are very dependent on good round trip times. >> Traditional DSL lines with ping times of 50-60ms can really slow down >> requests of small files a lot due to three-way tcp handshaking, that >> is, you could request only one smallish file per 100-120ms. This can >> totally destroy the usable bandwidth. Maybe watch a running ping >> while the downloads are running. If the ping times increase while the >> download slows down, your bottleneck is the upload. >> >> But also keep in mind that traditional spinning disks may not keep up >> with the bandwidth if confronted with many small files. If you're >> using SSD all should be fine. I'm running on bcache with writeback >> caching which gives a really good performance boost by adding a small >> SSD to one or more big HDDs. > > BTW: I don't see how dnsmasq could help you here... It can do nothing > about bandwidth. It only acts as a DNS cache which helps keeping > latency of the DNS resolver down. But this doesn't matter here because > during download, steam won't do many DNS requests. > > As already stated, part of the problem may be the upload, and/or bad > queue handling within your broadband router. You can work around it > with a traffic shaper and throttling upload below what's physically > possible with your internet line, thus keeping the queue in front of the > broadband router. That way, a traffic shaper could handle it and work > around bad queue handling. > > To resolve the issue it is important to sophistically test the > suggestions one step at a time, starting with the easy ones, and do > your measurements.
