* Problems with "Enable some performance tuning" => extremly slow downloads
@ 2019-02-20 10:18 Matthias Fischer
2019-02-20 15:40 ` Michael Tremer
0 siblings, 1 reply; 6+ messages in thread
From: Matthias Fischer @ 2019-02-20 10:18 UTC (permalink / raw)
To: development
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
Hi,
being curious, I tested commit
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d03916e55851a243594ebf6f0c20c8f6d9092277
on my Core 127 / 32bit IPFire.
At first I didn't notice any differences, system was running as usual.
No important performance impact or change.
But yesterday, while starting some bigger downloads and closely
watching, I noticed that everytime someone started to download a
somewhat bigger file, e.g. 250-800 MB, downloading rates went down to a
crawl. Some downloads even aborted and nearly all where amazingly slow
(~150KB/s, normal: ~6.5 MB/s).
Restarting our Fritzbox and IPFire itself didn't help, all downloads
stayed that way.
After reverting the above commit in '/etc/sysctl.conf' and running
'sysctl -p', system is running at full speed again: VDSL, 50Mbit down /
10Mbit up.
Configuration:
Duo Box with Core 127/32bit. Running 'privoxy 3.0.28', 'squid 4.6'
(non-transparent, 512 MB RAM only), 'squidguard 1.5 beta',
'squidclamav', 'snort / guardian', 'unbound 1.9.0' with DoT/TFO.
Could someone please test and confirm (or not ;-) ).
Best,
Matthias
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with "Enable some performance tuning" => extremly slow downloads
2019-02-20 10:18 Problems with "Enable some performance tuning" => extremly slow downloads Matthias Fischer
@ 2019-02-20 15:40 ` Michael Tremer
2019-02-21 0:36 ` Matthias Fischer
0 siblings, 1 reply; 6+ messages in thread
From: Michael Tremer @ 2019-02-20 15:40 UTC (permalink / raw)
To: development
[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]
Interesting… These settings shouldn’t have any impact on any connections going through the firewall.
Can you narrow it down to one specific setting of these by disabling one by one?
-Michael
> On 20 Feb 2019, at 10:18, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>
> Hi,
>
> being curious, I tested commit
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d03916e55851a243594ebf6f0c20c8f6d9092277
> on my Core 127 / 32bit IPFire.
>
> At first I didn't notice any differences, system was running as usual.
> No important performance impact or change.
>
> But yesterday, while starting some bigger downloads and closely
> watching, I noticed that everytime someone started to download a
> somewhat bigger file, e.g. 250-800 MB, downloading rates went down to a
> crawl. Some downloads even aborted and nearly all where amazingly slow
> (~150KB/s, normal: ~6.5 MB/s).
>
> Restarting our Fritzbox and IPFire itself didn't help, all downloads
> stayed that way.
>
> After reverting the above commit in '/etc/sysctl.conf' and running
> 'sysctl -p', system is running at full speed again: VDSL, 50Mbit down /
> 10Mbit up.
>
> Configuration:
> Duo Box with Core 127/32bit. Running 'privoxy 3.0.28', 'squid 4.6'
> (non-transparent, 512 MB RAM only), 'squidguard 1.5 beta',
> 'squidclamav', 'snort / guardian', 'unbound 1.9.0' with DoT/TFO.
>
> Could someone please test and confirm (or not ;-) ).
>
> Best,
> Matthias
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with "Enable some performance tuning" => extremly slow downloads
2019-02-20 15:40 ` Michael Tremer
@ 2019-02-21 0:36 ` Matthias Fischer
2019-02-21 9:33 ` Michael Tremer
0 siblings, 1 reply; 6+ messages in thread
From: Matthias Fischer @ 2019-02-21 0:36 UTC (permalink / raw)
To: development
[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]
Hi,
On 20.02.2019 16:40, Michael Tremer wrote:
> Interesting… These settings shouldn’t have any impact on any connections going through the firewall.
Yep. And at the moment, I'm not so sure they're really the cause because
it happened again.
At first, I thought it had something to do with my ISP. I made a call,
but they couldn't find anything wrong with the connection. The problem
would be on my side. Hm.
> Can you narrow it down to one specific setting of these by disabling one by one?
Right now: definitely NO. Its "under investigation".
Best,
Matthias
P.S.: Oh my - it was too late for something like this - just saw it: the
machine needs a reboot to really get rid of the tuned parameters, right!?
> -Michael
>
>> On 20 Feb 2019, at 10:18, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>
>> Hi,
>>
>> being curious, I tested commit
>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d03916e55851a243594ebf6f0c20c8f6d9092277
>> on my Core 127 / 32bit IPFire.
>>
>> At first I didn't notice any differences, system was running as usual.
>> No important performance impact or change.
>>
>> But yesterday, while starting some bigger downloads and closely
>> watching, I noticed that everytime someone started to download a
>> somewhat bigger file, e.g. 250-800 MB, downloading rates went down to a
>> crawl. Some downloads even aborted and nearly all where amazingly slow
>> (~150KB/s, normal: ~6.5 MB/s).
>>
>> Restarting our Fritzbox and IPFire itself didn't help, all downloads
>> stayed that way.
>>
>> After reverting the above commit in '/etc/sysctl.conf' and running
>> 'sysctl -p', system is running at full speed again: VDSL, 50Mbit down /
>> 10Mbit up.
>>
>> Configuration:
>> Duo Box with Core 127/32bit. Running 'privoxy 3.0.28', 'squid 4.6'
>> (non-transparent, 512 MB RAM only), 'squidguard 1.5 beta',
>> 'squidclamav', 'snort / guardian', 'unbound 1.9.0' with DoT/TFO.
>>
>> Could someone please test and confirm (or not ;-) ).
>>
>> Best,
>> Matthias
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with "Enable some performance tuning" => extremly slow downloads
2019-02-21 0:36 ` Matthias Fischer
@ 2019-02-21 9:33 ` Michael Tremer
2019-02-21 15:41 ` Matthias Fischer
2019-02-22 17:40 ` Matthias Fischer
0 siblings, 2 replies; 6+ messages in thread
From: Michael Tremer @ 2019-02-21 9:33 UTC (permalink / raw)
To: development
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
On 21 Feb 2019, at 00:36, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>
> Hi,
>
> On 20.02.2019 16:40, Michael Tremer wrote:
>> Interesting… These settings shouldn’t have any impact on any connections going through the firewall.
>
> Yep. And at the moment, I'm not so sure they're really the cause because
> it happened again.
>
> At first, I thought it had something to do with my ISP. I made a call,
> but they couldn't find anything wrong with the connection. The problem
> would be on my side. Hm.
>
>> Can you narrow it down to one specific setting of these by disabling one by one?
>
> Right now: definitely NO. Its "under investigation".
>
> Best,
> Matthias
>
> P.S.: Oh my - it was too late for something like this - just saw it: the
> machine needs a reboot to really get rid of the tuned parameters, right!?
No you can set these without a reboot...
>
>> -Michael
>>
>>> On 20 Feb 2019, at 10:18, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>
>>> Hi,
>>>
>>> being curious, I tested commit
>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d03916e55851a243594ebf6f0c20c8f6d9092277
>>> on my Core 127 / 32bit IPFire.
>>>
>>> At first I didn't notice any differences, system was running as usual.
>>> No important performance impact or change.
>>>
>>> But yesterday, while starting some bigger downloads and closely
>>> watching, I noticed that everytime someone started to download a
>>> somewhat bigger file, e.g. 250-800 MB, downloading rates went down to a
>>> crawl. Some downloads even aborted and nearly all where amazingly slow
>>> (~150KB/s, normal: ~6.5 MB/s).
>>>
>>> Restarting our Fritzbox and IPFire itself didn't help, all downloads
>>> stayed that way.
>>>
>>> After reverting the above commit in '/etc/sysctl.conf' and running
>>> 'sysctl -p', system is running at full speed again: VDSL, 50Mbit down /
>>> 10Mbit up.
>>>
>>> Configuration:
>>> Duo Box with Core 127/32bit. Running 'privoxy 3.0.28', 'squid 4.6'
>>> (non-transparent, 512 MB RAM only), 'squidguard 1.5 beta',
>>> 'squidclamav', 'snort / guardian', 'unbound 1.9.0' with DoT/TFO.
>>>
>>> Could someone please test and confirm (or not ;-) ).
>>>
>>> Best,
>>> Matthias
>>
>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with "Enable some performance tuning" => extremly slow downloads
2019-02-21 9:33 ` Michael Tremer
@ 2019-02-21 15:41 ` Matthias Fischer
2019-02-22 17:40 ` Matthias Fischer
1 sibling, 0 replies; 6+ messages in thread
From: Matthias Fischer @ 2019-02-21 15:41 UTC (permalink / raw)
To: development
[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]
Hi,
On 21.02.2019 10:33, Michael Tremer wrote:
> On 21 Feb 2019, at 00:36, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> On 20.02.2019 16:40, Michael Tremer wrote:
>>> Interesting… These settings shouldn’t have any impact on any connections going through the firewall.
>> ...
>>> Can you narrow it down to one specific setting of these by disabling one by one?
>> Right now: definitely NO. Its "under investigation".
>>
>> Best,
>> Matthias
>>
>> P.S.: Oh my - it was too late for something like this - just saw it: the
>> machine needs a reboot to really get rid of the tuned parameters, right!?
>
> No you can set these without a reboot...
It was a bit too late/early in the morning - I overlooked the defaults.
Current results:
No problems with DoT and:
vm.swappiness = 1
net.ipv4.tcp_fastopen = 3
Testing takes a while because this "degrading" happens without prior
notice and you don't notice it during normal surfing, only while
downloading.
Best,
Matthias
>
>>
>>> -Michael
>>>
>>>> On 20 Feb 2019, at 10:18, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> being curious, I tested commit
>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d03916e55851a243594ebf6f0c20c8f6d9092277
>>>> on my Core 127 / 32bit IPFire.
>>>>
>>>> At first I didn't notice any differences, system was running as usual.
>>>> No important performance impact or change.
>>>>
>>>> But yesterday, while starting some bigger downloads and closely
>>>> watching, I noticed that everytime someone started to download a
>>>> somewhat bigger file, e.g. 250-800 MB, downloading rates went down to a
>>>> crawl. Some downloads even aborted and nearly all where amazingly slow
>>>> (~150KB/s, normal: ~6.5 MB/s).
>>>>
>>>> Restarting our Fritzbox and IPFire itself didn't help, all downloads
>>>> stayed that way.
>>>>
>>>> After reverting the above commit in '/etc/sysctl.conf' and running
>>>> 'sysctl -p', system is running at full speed again: VDSL, 50Mbit down /
>>>> 10Mbit up.
>>>>
>>>> Configuration:
>>>> Duo Box with Core 127/32bit. Running 'privoxy 3.0.28', 'squid 4.6'
>>>> (non-transparent, 512 MB RAM only), 'squidguard 1.5 beta',
>>>> 'squidclamav', 'snort / guardian', 'unbound 1.9.0' with DoT/TFO.
>>>>
>>>> Could someone please test and confirm (or not ;-) ).
>>>>
>>>> Best,
>>>> Matthias
>>>
>>>
>>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Problems with "Enable some performance tuning" => extremly slow downloads
2019-02-21 9:33 ` Michael Tremer
2019-02-21 15:41 ` Matthias Fischer
@ 2019-02-22 17:40 ` Matthias Fischer
1 sibling, 0 replies; 6+ messages in thread
From: Matthias Fischer @ 2019-02-22 17:40 UTC (permalink / raw)
To: development
[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]
Hi,
On 21.02.2019 10:33, Michael Tremer wrote:
> On 21 Feb 2019, at 00:36, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>
>> Hi,
>>
>> On 20.02.2019 16:40, Michael Tremer wrote:
>>> Interesting… These settings shouldn’t have any impact on any connections going through the firewall.
>> ...
>> ...
>>> Can you narrow it down to one specific setting of these by disabling one by one?
>> ...
Yes. And I finished testing:
I would say: "case can be closed".
I wasn't able to track this down to one of the tuned parameters of the
commit cited below. Must be another reason.
I activated options one by one and tested with simple 1GB / 5GB download
files from Netcologne and Hetzner.
Now all parameters are active again => downloads still run at normal
speed. This means 7.0MB/sec - with peaks at 7.6MB/sec - which is
absolutely ok for our line.
Mostly it happened in the evening or at night. I'll see what happens then.
Best,
Matthias
>>
>>> -Michael
>>>
>>>> On 20 Feb 2019, at 10:18, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> being curious, I tested commit
>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d03916e55851a243594ebf6f0c20c8f6d9092277
>>>> on my Core 127 / 32bit IPFire.
>>>>
>>>> At first I didn't notice any differences, system was running as usual.
>>>> No important performance impact or change.
>>>>
>>>> But yesterday, while starting some bigger downloads and closely
>>>> watching, I noticed that everytime someone started to download a
>>>> somewhat bigger file, e.g. 250-800 MB, downloading rates went down to a
>>>> crawl. Some downloads even aborted and nearly all where amazingly slow
>>>> (~150KB/s, normal: ~6.5 MB/s).
>>>>
>>>> Restarting our Fritzbox and IPFire itself didn't help, all downloads
>>>> stayed that way.
>>>>
>>>> After reverting the above commit in '/etc/sysctl.conf' and running
>>>> 'sysctl -p', system is running at full speed again: VDSL, 50Mbit down /
>>>> 10Mbit up.
>>>>
>>>> Configuration:
>>>> Duo Box with Core 127/32bit. Running 'privoxy 3.0.28', 'squid 4.6'
>>>> (non-transparent, 512 MB RAM only), 'squidguard 1.5 beta',
>>>> 'squidclamav', 'snort / guardian', 'unbound 1.9.0' with DoT/TFO.
>>>>
>>>> Could someone please test and confirm (or not ;-) ).
>>>>
>>>> Best,
>>>> Matthias
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-02-22 17:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-20 10:18 Problems with "Enable some performance tuning" => extremly slow downloads Matthias Fischer
2019-02-20 15:40 ` Michael Tremer
2019-02-21 0:36 ` Matthias Fischer
2019-02-21 9:33 ` Michael Tremer
2019-02-21 15:41 ` Matthias Fischer
2019-02-22 17:40 ` Matthias Fischer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox