Core Update 198 cut my internet speed in half - sort of

Getting Started with IPFire Updates Trouble
1

Hi guys,

I’ve updated to cu 198 just after release and noticed quite quickly, that my “automatic internet check” using speedtest dropped to 50%. However, when checking in the browser using both speedtest.net and fast.com didn’t show any problems, but downloading bigger files did. Funny enough, when downloading a file (with ~50% speed) and checking the speed using a browser it in combination also showed me the full speed.

This happened immediately after updating, here you can see how it dropped and it stayed like this since:

image
image658×365 15.3 KB

To exclude any other network issues, I’ve also used the speedtest-cli addon on the IPFire, but that showed the same result:

Retrieving speedtest,net server list…
Selecting best server based on ping…
Hosted by [0 km]: 17.132 ms

Testing download speed…
Download: 43.51 Mbit/s
Testing upload speed…
Upload: 35.79 Mbit/s

I don’t have any QoS activated, so everything should get the same speed. The most surprise I have, is that browser based testing shows the same speed, but CLI or downloads are slower. There haven’t been any other changes to the IPFire configuration or hardware, that would explain this dropped…

Do you have any glue or hint, where this might come from?

TL;DR: Internet connection speed dropped to 50% for downloads and CLI, but browser testing using like speedtest shows still 100% of the speed.

Thanks for any tips

1 Like
2

The only thing that I know that change is the CPU governor.

Some hardware maybe affected by this more than others?

3

And anyway.. it’s possible to have reported more data on your setup (mainboard, cpu, network cards or device brand and model)

According to this post

the latest kernel is based on Linux 6.12.41 and CU 198 did not mentioned any kernel change, so at least by drivers everything should be the same… Was CU197 skipped?

CU198 introduces newer intel Microcodes, which could deliver some performance drawbacks (mostly of the times under 10%…)

2 Likes
4

Thanks for your replies. I’m having this setup running for many years already and usually I’m installing the latest core updates quite quickly, over the years I maybe missed only a couple, so yes, cu 197 has been installed and as promised I saw a big drop in CPU usage, but not in internet speed.

The hardware I’m using is a PC Engine APU2, which is running with an “AMD GX-412TC SOC” 4 core CPU and 4GB Memory. Network wise it has three NICs, but I can’t tell from heart, which are those. I try to find the exact APU model later.

It’s using the latest kernel, so that is “6.12.41-ipfire” and the latest available firmware (4.19.0.1-16).

I’ve just tested it again, but the CPU usage is jumping to ~40% max when running speedtest multiple times, therefore I can’t imagine, that there is a real hardware issue. But true, the board and CPU are pretty old, so there might have been a microcode update, that causes this issue.

2 Likes
5

the HW can’t be the culprit - i am using APU2c4 too without any hickups @ my DSL100 Connection

2 Likes
6

IMVHO that cannot be said for sure. But your info reported that might be anyway powerful enough to sustain a 100mbs download.

@ducky did you verified if for instance the connection between your APU2 and your CPE might be degraded to half duplex?

7

That’s true - i have to be more precise: the HW can’t be the culprit in this Case :wink:

my APU has QoS enabled and runs like a charm with VDSL100

8

Roll back to 197 and check if 198 is to be blamed.

9

:thinking:

Have you checked whether speedtest-cli in the IPFire console and speedtest in the browser connect to the same speedtest server?

obraz

obraz
obraz319×395 12 KB

Do you use the --secure switch for testing in the IPFire console?

10

Well, this is my home setup, so rolling back would be quite an act, I’ve also never done it though and the installation is a couple of years in the past… But yes, that would be an option…

11

I actually run it behind an Vigor167, so no CPE included. This is also running for a couple of months now (since my FritzBox died) and there wasn’t any change I know. The Vigor also shows the same DSL information as before (yes, not the best line, but that’s what I have…):

image
image709×855 17.8 KB

The thing that is strange to me, I had a line degradation in the past, but that was only around ~15% and I could see it in the FritzBox DSL stats (at that time). This time, it is only visible when having actual downloads or using the speedtest-cli, but not on browser side (or using speedtest in the browser). As I said, when I’m downloading something and starting speedtest in the browser, the IPFire UI shows the full speed used in the UI, but when the test in the browser is done it falls back to ~50%. So I can’t imagine a line degredation here and from the past I know, that the ISP will ask me to do a speedtest in the browser…

12

Good point, I’ve just tested it again making sure, to use the same server and also used the “–secure” flag. The picture is the same:

Selecting best server based on ping…
Hosted by Net-D-Sign GmbH (Munich) [0 km]: 20.915 ms
Testing download speed…
Download: 44.65 Mbit/s
Testing upload speed…
Upload: 35.66 Mbit/s

image
image413×310 22.3 KB

13

really strange - my Setup looks almost exactly the same

I also use a Vigor 165 as a DSL modem…

you really sure that QoS is not running in Background? i have some strange behaviour in the past: even QoS was deactivated it was running…

disable all QoS and check /var/ipfire/qos

classes

level7config

portconfig

settings

subclasses

tosconfig

all Files sizes should be 0 - if not delete all it’s contents

after that reboot

14

Thanks for the hint. I’ve checked it and indeed, the files had some content. I’ve emptied them and rebooted but still the same :frowning:

15

Just for information

The author of speedtest-cli posted the following information on his GitHub page:

It is not a goal of this application to be a reliable latency reporting tool.

Latency reported by this tool should not be relied on as a value indicative of ICMP style latency. It is a relative value used for determining the lowest latency server for performing the actual speed test against.

There is the potential for this tool to report results inconsistent with Speedtest.net. There are several concepts to be aware of that factor into the potential inconsistency:

Speedtest.net has migrated to using pure socket tests instead of HTTP based tests
1.This application is written in Python
2.Different versions of Python will execute certain parts of the code faster than others
3.CPU and Memory capacity and speed will play a large part in inconsistency between Speedtest.net and even other machines on the same network

Issues relating to inconsistencies will be closed as wontfix and without additional reason or context.

edit
The official Ookla speedtest CLI command line client is available on the following page.

obraz
obraz339×550 15.6 KB