High CPU consumption in v4.6 due to [1] a TCP/IP stack implementation bug, [2] Statistics algorithm

[ameshkov]

Please answer the following questions for yourself before submitting an issue

• Filters were updated before reproducing an issue
• I checked the knowledge base and found no answer
• I checked to make sure that this issue has not already been filed

AdGuard version

v4.6.4 (204) or newer

Issue Details

The issue was originally reported by @derKief, check out the logs analysis here:
#5499 (comment)

To sum it up, AdGuard v4.6 consumes several times more than v4.5

UPDATE:
If you look through the issue comments, you'll see that we found two different issues here.

1. One issue is due to a race condition in the TCP/IP stack implement. VERY random bug, hard to catch.
2. The other issue is due to the statistics implementation. Temporary solution: clear stats.

Actual Behavior

The usage should be more or less the same in v4.5 and v4.6.

[ameshkov]

Things to check:

1. Is it specific to Samsung?
2. One thing that's unusual compared to regular configuration is that DNS protection is disabled and Android's private DNS is used instead.

[derKief]

@ameshkov

• Is it specific to Samsung? My other device that has the same symptoms is also a Samsung -> Galaxy S24 (SM-S921B/DS)

• One thing that's unusual compared to regular configuration is that DNS protection is disabled and Android's private DNS is used instead. I changed it during the whole troubleshooting because I suspected it, but it makes no difference.

[0xrxL]

I don't know about 4.6, but this is the last stats from Nightly 44:

and CPU foreground usage is weirdly high, despite system battery usage is 1.6%.

[0xrxL]

@ameshkov Can this usage related to this issue in any way?

P.S: I have a S23 Plus however.

[ameshkov]

@0xrxL if this is a 24-hours usage then it looks good to me.

@derKief on the contrary faces a real issue. We've been trying to reproduce it on Samsung devices yesterday but no success so far.

[ameshkov]

@derKief just in case, could you please try nighlty version of AG? It has just minor improvements, but for some reason we don't see reports from Samsung owners on the nightly build (and the two I saw on GH seem to have normal usage).

[abryant-hv]

Ever since at least 4.6.4, Adguard has been the top consumer of battery life on my (Samsung) phone every time I've checked, with no change in my usage of the phone. I'll try the nightly today, but 4.6.204 definitely did not fix the issues. And yes, I have sent the logs to support, but I got an email this morning closing the ticket, with no other information.

I don't want to just pile on this ticket with a useless comment, but this issue is definitely not resolved with 4.6.204.

[PavelParkhomenko]

And yes, I have sent the logs to support, but I got an email this morning closing the ticket, with no other information.

We responded to you yesterday in ticket #978524 before closing it. In our response, we informed you that the app logs were forwarded to our development team and provided a link to this issue so you can track further progress.

[abryant-hv]

Yes there was a link to this issue, which is why I'm here. It sounded above like victory was being declared a bit too early, but perhaps I misread that.

Back on topic, I've used the v4.7 Nightly 44 this morning for about 3 hours, and AdGuard has used 19.1% of my battery in that time, 3 times more than the next app. Device battery usage is still higher than normal with the latest nightly. :(

[ameshkov]

@abryant-hv what exact Samsung model are you using just in case?

[abryant-hv]

It's a "Galaxy A52 5G". Model name is "SM-A526U"

[derKief]

with the Nightly 44 (4.7.89) it has gotten better but in direct comparison to the stable 4.5 it is still too high/much.
Tested with the SM-A256B (Galaxy A25). My other phone the Galaxy S24 is still on v4.5 and will remain so until the problem is resolved.

@ameshkov I replied to your private e-mail. Waiting on feedback.

[derKief]

Today I tried to update to the new 4.7 Nightly 45, but it didn't work. The app crashed and wouldn't start anymore.
Since I don't really have the time to do any more error analysis, I've gone back to the stable version 4.5, which works
without any problems. Hopefully this is fixed soon ....

[0xrxL]

Today I tried to update to the new 4.7 Nightly 45, but it didn't work. The app crashed and wouldn't start anymore. Since I don't really have the time to do any more error analysis, I've gone back to the stable version 4.5, which works without any problems. Hopefully this is fixed soon ....

Mhh...weirdly in my case the Nightly 45 (at least for the moment) seems to be very optimised. Check it out here:

[Cb1231ct]

Had this been fixed yet. I had to turn it off the drain was so bad. Where can I find 4.5th go back to it

[jordansworld]

no. i would just go back to 4.5 for now

[Cb1231ct]

Yes where is it to download please

[jordansworld]

https://www.apkmirror.com/apk/adguard-software-limited/adguard/adguard-4-5-25-release/

[derKief]

or directly from here -> https://github.com/AdguardTeam/AdguardForAndroid/releases/tag/v4.5

[solkarnar]

I know it's a Samsung ticket but i have the same problem on a Xiaomi Phone. I have reverted to 4.5 and will be watching this ticket to see if any solutions manifests itself.

[jordansworld]

good to know its an all around issue

[muchqs]

I don't think the 4.6 build 204 Hotfix version completely fixed the problem. The battery drain caused by the calendar timezone change when phone is idle is gone. However the app still seems to cause very high CPU usage when it's not idle, causing phone to heat up badly and battery goes down insanely fast.

I posted here. The AdGuard battery stat screen shows 24-hour usage is normal, but when I use the phone, CPU temp goes through the roof, approaching around 80C sometimes in as little as 2-5 minutes. And the battery drops super fast. The phone becomes a very effective hand warmer.

I noticed this while using the Bing app and AliExpress app in particular.

I went back to v4.5. Phone still got warm while using those apps but not as much as the v4.6 build 204 Hotfix version.

v4.6 build 204 Hotfix - CPU temp 70-80C while using apps. Temp consistently above 70C with spikes to 80C.

v4.5 - CPU temp 60-70C while using apps. Temp around 60C with a few spikes to 70C.

phone is Vivo X100 Pro.

[derKief]

I know it's a Samsung ticket but i have the same problem on a Xiaomi Phone. I have reverted to 4.5 and will be watching this ticket to see if any solutions manifests itself.

I can now confirm that this is not just a Samsung problem. My wife's Poco X6 Pro is also affected and here too we are back to v4.5

[0xrxL]

Heh...Unfortunately, today the latest Nightly started to drain my battery again, and this after starting to watch a TV series from web browser. This problem didn't happen during normal navigation, maybe this can helpful to find the root of problem @ameshkov?

[unknown4849]

Xiaomi (poco F6) too. i first think my devices broken XD. after restart and start adguard seem fine.

security patch same 2024-10 -1, could this be the cause? i feel before update to this patch don't have this problem, but after update at today i got this problem CPU locked at high speed (via CPUZ)

[muchqs]

I don't think the 4.6 build 204 Hotfix version completely fixed the problem. The battery drain caused by the calendar timezone change when phone is idle is gone. However the app still seems to cause very high CPU usage when it's not idle, causing phone to heat up badly and battery goes down insanely fast.

I posted here. The AdGuard battery stat screen shows 24-hour usage is normal, but when I use the phone, CPU temp goes through the roof, approaching around 80C sometimes in as little as 2-5 minutes. And the battery drops super fast. The phone becomes a very effective hand warmer.

I noticed this while using the Bing app and AliExpress app in particular.

I went back to v4.5. Phone still got warm while using those apps but not as much as the v4.6 build 204 Hotfix version.

v4.6 build 204 Hotfix - CPU temp 70-80C while using apps. Temp consistently above 70C with spikes to 80C.

v4.5 - CPU temp 60-70C while using apps. Temp around 60C with a few spikes to 70C.

phone is Vivo X100 Pro.

I downgraded even more today to v4.4.1 as I find even with v4.5 the CPU temp seems rather elevated.
And initial results show that indeed, v4.4.1 is better than v4.5.

Before testing v4.4.1, CPU temp was 100% under 40C.
After using AliExpress app for around 15 min, CPU temp was 100% above 40C, but also all under 50C except one single spike to 50C.
Used the Bing app for 14 min. CPU temp was still consistently between 40C to 50C, never above 50C.

on v4.5, after using the same apps, CPU temp would be between 60-70C.

so far my results:
v4.6 hotfix - CPU temp 70-80C
v4.5 - CPU temp 60-70C
v4.4.1 - CPU temp 40-50C.

gonna do the same tests again tomorrow.

[ameshkov]

@0xrxL why do you think it's a "drain" and not a normal usage? Did it stop after you finished watching? Is it specific to that website?

[ameshkov]

@muchqs tbh temperature numbers do not provide us with any insights into the issue.

AdGuard prints CPU usage numbers measured by the system, it'd be helpful if you compare them between different versions.

Basically, we need every record in the log that contains Calculated battery usage (it's printed to the normal INFO log as well). I explained them here: #5499 (comment)

[jordansworld]

im curious to see if different phone brands have different issues?

[ameshkov]

@jordansworld the only person for whom I saw this TCP bug happening is @derKief, everyone else in this thread was suffering from a different one :)

We created quite a bit of confusion by solving both of them in one issue, I should've filed a different one.

[derKief]

@ameshkov
atm i'm testing on my main device an Samsung S25 ... as mentioned that looks promising at the moment.
The device you are talking about (TCP bug) is my second device an Samsung A25.
I don't have Adguard installed on it atm. I want to wait for the test on the S25 first.
One thing at a time ;-)

[ameshkov]

@jordansworld please, pass the logs via email ([email protected]), debug-level logging is not supposed to be shared on Github.

[jordansworld]

@ameshkov sent. The file is 95mb so i had to upload via a file host

[derKief]

@ameshkov
i installed Stable 4.8 also on my Samsung A25. The extended logging was activated ~ last 3 hours. The logs just sent.
It seems that A25 is also running fine for now.
Will continue testing on both devices S25 & A25.

[0xrxL]

@derKief Try to use the app in foreground (for example: go on statistics and/or into settings) for 10 minutes at least, and check if the battery consuption will increase over 1%. This could be another unfixed power drain.

[jordansworld]

were you guys able to check my logs? @0xrxL

[0xrxL]

were you guys able to check my logs? @0xrxL

I'm not an adguard dev 😅

Wait a response from @ameshkov

[jordansworld]

were you guys able to check my logs? @0xrxL

I'm not an adguard dev 😅

Wait a response from @ameshkov

ohh 🤣🤣🤣

[derKief]

A short interim report.
The A25 does use more battery power compared to the S25, even though it is not used as much as the S25.
In particular, the CPU background usage on the A25 is much higher. Checked and compared with the in-app statistics.
So for now I would currently say:
S25 is good.
A25 is not really good resp. could be better.

@ameshkov did you already analyze the A25 logs i sent you? Any abnormalities ?

[jordansworld]

i think the app uses alot of battery when ur using it in the foreground.

[derKief]

The main difference in the use of my two devices is that I almost only use the native apps on the S25, but do almost everything in the browser on the A25. But that doesn't explain the increased CPU background usage on the A25 compared to the S25.

[TPS]

The main difference in the use of my two devices is that I almost only use the native apps on the S25, but do almost everything in the browser on the A25. But that doesn't explain the increased CPU background usage on the A25 compared to the S25.

Actually might! Browser is more intensively filterable than average app, so presumably uses more CPU from AG.

Maybe try more apples-to-apples via shifting usage pattern on 1 device to match other's & see whether stats reflect that?

[derKief]

Actually might! Browser is more intensively filterable than average app, so presumably uses more CPU from AG.

I am aware of that ... but if you look closely I wrote about background CPU not foreground CPU

Maybe try more apples-to-apples via shifting usage pattern on 1 device to match other's & see whether stats reflect that?

I agree with you... but I have no desire to adjust everything.

[TPS]

I am aware of that ... but if you look closely I wrote about background CPU not foreground CPU

Both do filtering (I'm unaware precisely which filtering is separated into foreground/background 🤷🏾‍♂️), so Idk why that's relevant?

[ameshkov]

@derKief hi, thanks for the logs!

I've skimmed to it and generally the usage does not seem too high, not even close to what it was before. According to the log the total CPU usage for the day (starting at 8am to 9pm) seems to be about 6.5-7 minutes of CPU time which is completely fine.

The heaviest period was between 18:19 and 18:42 when AdGuard used about 70 seconds of CPU time.
In that period AdGuard has filtered 1338 HTTP requests and 702 DNS requests.

background CPU not foreground CPU

Foreground means CPU usage when AdGuard UI is open, i.e. when you use the app UI.
Rendering UI is generally much heavier than doing the filtering itself, that's why there's a distinction in our stats.

But that doesn't explain the increased CPU background usage on the A25 compared to the S25.

Do you compare CPU usage minutes or mAh? S25 has 8 CPU cores and A25 has 4 CPU cores so CPU minutes are translated to a twice smaller usage on S25. For better understanding, CPU time is roughly equal to the total time a single CPU core was running with 100% load.

Also, @TPS is right about filtering browser being a more complicated task than everything else as it includes HTTPS filtering.

All in all, I don't see any issues with it in the log.

The problem is that I don't see the original TCP bug there either. My only assumption is that it was somehow triggered by the increased usage caused by the statistics module and now since it's fixed it's not triggered anymore. Well, better than nothing.

@jordansworld I checked your log, it's also fine, thank you!

[derKief]

@ameshkov thanks a lot for checking the logs and the the good explanation.