[gentoo-user] Re: Steam downloading extremely

[Kai Krakow]

Am Thu, 16 Mar 2017 14:04:14 +0800
schrieb Danny YUE <sheepduke@×××××.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 <hurikhan77@×××××.com> wrote:
> > Am Wed, 15 Mar 2017 21:53:44 +0100
> > schrieb Kai Krakow <hurikhan77@×××××.com>:
> >
> >> Am Wed, 15 Mar 2017 21:24:10 +0800
> >> schrieb Danny YUE <sheepduke@×××××.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.