From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Problems with "Enable some performance tuning" => extremly slow downloads
Date: Thu, 21 Feb 2019 01:36:01 +0100 [thread overview]
Message-ID: <086c745c-61c4-784c-739a-588ded7ca64c@ipfire.org> (raw)
In-Reply-To: <A8C0C5C4-09ED-457D-94D2-7F6C0F8F19E7@ipfire.org>
[-- 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
>
>
next prev parent reply other threads:[~2019-02-21 0:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 10:18 Matthias Fischer
2019-02-20 15:40 ` Michael Tremer
2019-02-21 0:36 ` Matthias Fischer [this message]
2019-02-21 9:33 ` Michael Tremer
2019-02-21 15:41 ` Matthias Fischer
2019-02-22 17:40 ` Matthias Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=086c745c-61c4-784c-739a-588ded7ca64c@ipfire.org \
--to=matthias.fischer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox