| 1 |
Hi Kai, |
| 2 |
|
| 3 |
Oops, fixed? |
| 4 |
|
| 5 |
I just updated my system and tried to randomly download another game |
| 6 |
and it looks fine... |
| 7 |
|
| 8 |
Weird. |
| 9 |
|
| 10 |
Anyway, thanks for you guys. |
| 11 |
May the good code be with you. |
| 12 |
|
| 13 |
Danny |
| 14 |
|
| 15 |
|
| 16 |
On 2017-03-19 19:11, Kai Krakow <hurikhan77@×××××.com> wrote: |
| 17 |
> Am Thu, 16 Mar 2017 14:04:14 +0800 |
| 18 |
> schrieb Danny YUE <sheepduke@×××××.com>: |
| 19 |
> |
| 20 |
>> Hi Kai, |
| 21 |
>> |
| 22 |
>> Thanks for your help :-) |
| 23 |
>> |
| 24 |
>> Code here: |
| 25 |
>> /usr/share/info $ cat /proc/sys/net/ipv4/tcp_fastopen |
| 26 |
>> 1 |
| 27 |
>> /usr/share/info $ cat /proc/sys/net/core/default_qdisc |
| 28 |
>> pfifo_fast |
| 29 |
>> /usr/share/info $ cat /proc/sys/net/ipv4/tcp_congestion_control |
| 30 |
>> cubic |
| 31 |
>> |
| 32 |
>> dnsmasq may help because...if my understanding is correct, Steam Linux |
| 33 |
>> client has a bug that it tries to query the DNS too often during |
| 34 |
>> downloading, then its request got throttled. Please see |
| 35 |
>> https://wiki.gentoo.org/wiki/Steam/Client_troubleshooting |
| 36 |
>> Section "Slow download speeds". |
| 37 |
> |
| 38 |
> This has been fixed with the March 9th 2017 Update. It's in the current |
| 39 |
> stable client. |
| 40 |
> |
| 41 |
>> For disk, I don't think it fits my case because for a downloading |
| 42 |
>> speed of 100KB/s, disk write should not be a bottleneck. |
| 43 |
> |
| 44 |
> Well, it still can be if there's a lot of data backlogged and the |
| 45 |
> writeback cache of the kernel is saturated. |
| 46 |
> |
| 47 |
>> I suspect it is related to Linux client because Steam Windows client |
| 48 |
>> on my machine downloads at the normal speed... |
| 49 |
> |
| 50 |
> This makes sense... However, here the linux client is downloading at 48 |
| 51 |
> mbytes/s which is pretty much the maximum of my 400 mbit link. |
| 52 |
> |
| 53 |
> So, if it is still slow for you, there seem to be other issues. |
| 54 |
> |
| 55 |
>> Well, I am not that familiar with network tuning things...so I will |
| 56 |
>> definitely check the methods you mentioned. |
| 57 |
> |
| 58 |
> Feel free to ask. |
| 59 |
> |
| 60 |
>> On 2017-03-15 21:07, Kai Krakow <hurikhan77@×××××.com> wrote: |
| 61 |
>> > Am Wed, 15 Mar 2017 21:53:44 +0100 |
| 62 |
>> > schrieb Kai Krakow <hurikhan77@×××××.com>: |
| 63 |
>> > |
| 64 |
>> >> Am Wed, 15 Mar 2017 21:24:10 +0800 |
| 65 |
>> >> schrieb Danny YUE <sheepduke@×××××.com>: |
| 66 |
>> >> |
| 67 |
>> [...] |
| 68 |
>> >> |
| 69 |
>> >> Here, it's downloading with peak bandwidths of 48 mbytes/s but |
| 70 |
>> >> usually it's around 38 mbytes/s. However, I sometimes see |
| 71 |
>> >> slowdowns, too. I guess that games are downloaded file by file, |
| 72 |
>> >> and when a lot of small files are left in the queue, it just |
| 73 |
>> >> cannot get good bandwidth. |
| 74 |
>> >> |
| 75 |
>> >> But I only see such slowdowns mostly short before the last few |
| 76 |
>> >> megabytes of a game. |
| 77 |
>> >> |
| 78 |
>> >> Could you check if your downloaded games consist of many smallish |
| 79 |
>> >> files? Then that could be the explanation. |
| 80 |
>> >> |
| 81 |
>> >> You could try activating fq_codel and tcp fastopen: |
| 82 |
>> >> |
| 83 |
>> >> In /proc/sys/net/ipv4/tcp_fastopen it should say 1. |
| 84 |
>> >> In /proc/sys/net/core/default_qdisc it should say fq_codel. |
| 85 |
>> >> |
| 86 |
>> >> Also, you may want to try out bbr congestion control: |
| 87 |
>> >> |
| 88 |
>> >> In /proc/sys/net/ipv4/tcp_congestion_control it should say bbr. |
| 89 |
>> >> |
| 90 |
>> >> By recompiling the kernel, you can reconfigure the defaults for |
| 91 |
>> >> this (and enable support). Some of these need modern kernels. |
| 92 |
>> >> |
| 93 |
>> >> Additionally, many small tcp request need a good portion of your |
| 94 |
>> >> upload bandwidth and are very dependent on good round trip times. |
| 95 |
>> >> Traditional DSL lines with ping times of 50-60ms can really slow |
| 96 |
>> >> down requests of small files a lot due to three-way tcp |
| 97 |
>> >> handshaking, that is, you could request only one smallish file per |
| 98 |
>> >> 100-120ms. This can totally destroy the usable bandwidth. Maybe |
| 99 |
>> >> watch a running ping while the downloads are running. If the ping |
| 100 |
>> >> times increase while the download slows down, your bottleneck is |
| 101 |
>> >> the upload. |
| 102 |
>> >> |
| 103 |
>> >> But also keep in mind that traditional spinning disks may not keep |
| 104 |
>> >> up with the bandwidth if confronted with many small files. If |
| 105 |
>> >> you're using SSD all should be fine. I'm running on bcache with |
| 106 |
>> >> writeback caching which gives a really good performance boost by |
| 107 |
>> >> adding a small SSD to one or more big HDDs. |
| 108 |
>> > |
| 109 |
>> > BTW: I don't see how dnsmasq could help you here... It can do |
| 110 |
>> > nothing about bandwidth. It only acts as a DNS cache which helps |
| 111 |
>> > keeping latency of the DNS resolver down. But this doesn't matter |
| 112 |
>> > here because during download, steam won't do many DNS requests. |
| 113 |
>> > |
| 114 |
>> > As already stated, part of the problem may be the upload, and/or bad |
| 115 |
>> > queue handling within your broadband router. You can work around it |
| 116 |
>> > with a traffic shaper and throttling upload below what's physically |
| 117 |
>> > possible with your internet line, thus keeping the queue in front |
| 118 |
>> > of the broadband router. That way, a traffic shaper could handle it |
| 119 |
>> > and work around bad queue handling. |
| 120 |
>> > |
| 121 |
>> > To resolve the issue it is important to sophistically test the |
| 122 |
>> > suggestions one step at a time, starting with the easy ones, and do |
| 123 |
>> > your measurements. |
| 124 |
>> |
| 125 |
>> |
Archives