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@ipfire.org wrote:
Hi,
being curious, I tested commit https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d03916e55851a243594ebf6f... 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