Am Thu, 16 Mar 2017 14:04:14 +0800 schrieb Danny YUE <sheepd...@gmail.com>:
> 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". This has been fixed with the March 9th 2017 Update. It's in the current stable client. > 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. Well, it still can be if there's a lot of data backlogged and the writeback cache of the kernel is saturated. > I suspect it is related to Linux client because Steam Windows client > on my machine downloads at the normal speed... This makes sense... However, here the linux client is downloading at 48 mbytes/s which is pretty much the maximum of my 400 mbit link. So, if it is still slow for you, there seem to be other issues. > Well, I am not that familiar with network tuning things...so I will > definitely check the methods you mentioned. Feel free to ask. > 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>: > >> > [...] > >> > >> 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. > > -- Regards, Kai Replies to list-only preferred.
