Created attachment 141200 [details] TCP keepalive packets in wireshark SUMMARY I couldn't help but notice in Wireshark that my KDE Neon workstation and my phone exchange 12 TCP keepalive packets per minute. Such a rate doesn't seem reasonable at all and I am concerned that it drains my phone battery for no good reason. STEPS TO REPRODUCE 1. Pair KDE Connect on a workstation to a phone. 2. Start Wireshark on the workstation. OBSERVED RESULT 12 TCP keepalive packets per minute between the workstation and the phone. EXPECTED RESULT No TCP keepalive packets. Or configurable TCP keepalive interval, with an option to disable keepalive completely. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon 5.22 KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION https://github.com/KDE/kdeconnect-kde/blob/664da445ee1ad5b63727cd0453bb6ca8364f50ea/core/backends/lan/lanlinkprovider.cpp#L575
Indeed. Right now everything is hardcoded. Idle (initial) interval is 10 seconds, interval between packets if no reply received is 5 seconds. This is WAY too frequent for mobile device.
https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/447
A workaround to configure TCP keepalive timeout for kdeconnectd until the application makes this timeout configurable: https://github.com/max0x7ba/kdeconnect-powersave-keepalive
(In reply to Maxim Egorushkin from comment #3) > A workaround to configure TCP keepalive timeout for kdeconnectd until the > application makes this timeout configurable: > https://github.com/max0x7ba/kdeconnect-powersave-keepalive Could you please make a test of cellphone battery consumption with 5 second keep-alives vs longer keep-alives please? I was asked to justify the modification in https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/447#note_388849, but always forgot to make a clean test.
(In reply to valdikss from comment #4) > (In reply to Maxim Egorushkin from comment #3) > > A workaround to configure TCP keepalive timeout for kdeconnectd until the > > application makes this timeout configurable: > > https://github.com/max0x7ba/kdeconnect-powersave-keepalive > > Could you please make a test of cellphone battery consumption with 5 second > keep-alives vs longer keep-alives please? The developers must provide justification for these rather frequent TCP keepalive messages when communicating with battery-powered devices. Without justification I consider this hard-coded 5-second TCP keepalive timeout leftover debugging code that the developers forgot to remove. There is no value for this timeout which works for any and all use cases. This timeout must be user-configurable. > I was asked to justify the modification in > https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/ > 447#note_388849, but always forgot to make a clean test. I cannot do that for you, I am sorry. IMO, it is rather the authors who must justify the rather short TCP keepalive timeout and prove that it doesn't result in increased battery drain.
Longer story about this bug report. My OnePlus 7T Pro McLaren would go 2 days without charge in my routine, with day 2 morning charge above 55% for the first 8 months, I was quite impressed. Then suddenly day 2 morning charge became ~38%. I examined phone battery stats and there was Android System being top battery consumer with 25%+, which I hadn't seen being above 10% before. I wasn't able to find the cause of Android System battery drain at the time and had to switch to charging the phone every night. A few weeks later I started Wireshark on my workstation for unrelated task and couldn't help but notice these 5-second keepalive TCP messages between KDE Connect on the workstation and the phone. The phone with its screen off replied to all these keepalive messages, which looked excessive and unnecessary. I uninstalled KDE Connect app from my phone, went on with my task, charged the phone overnight. Next day at charge time the remaining charge was above 60% and Android System battery usage went lower than 10%. I switched back to charging the phone once in 2 days. I had to make this workaround because it makes 2x difference for me in how often the phone needs to be charged.
Battery power is a limited resource but 5-second keepalive frequency expends it at high rate without consideration. The user may know best how much battery power they would be willing to expend for the immediacy of disconnect detection, or how much disconnect detection delay they can tolerate. And that may depend on the intended usage in the near future, or the network, or connection type, or particular device, etc.. Making this setting user configurable from both the desktop app and the mobile app would be the ideal solution - a win-win for users and developers.
(In reply to Maxim Egorushkin from comment #5) > The developers must provide justification for these rather frequent TCP > keepalive messages when communicating with battery-powered devices. As in the PR vladikss linked: If the keepalive is set higher, it will falsely tell users that the phone is connected when it is in fact not. Please do the test as requested by vladikss. Without some evidence that a change actually makes a difference, it's just a random number.
In particular, this claim is unsubstantiated from the evidence in this bug: (In reply to Maxim Egorushkin from comment #7) > Battery power is a limited resource but 5-second keepalive frequency expends > it at high rate without consideration. The only test mentioned is the app installed vs. uninstalled. There could be any number of other explanations for this. Maybe you use an app on the desktop with a very chatty MPRIS implementation, for instance. https://bugs.kde.org/show_bug.cgi?id=442782 You apparently have a workaround which changes the keepalive frequency. I assume you're happy with the battery life after applying the questions. Can you quantify that?
(In reply to Simon Redman from comment #9) > In particular, this claim is unsubstantiated from the evidence in this bug: Your response is little more than arrogant anti-scientific dismissals and denials, I am afraid. Which makes you a part of the problem, rather than solution, in my opinion.
(In reply to Simon Redman from comment #8) > (In reply to Maxim Egorushkin from comment #5) > > The developers must provide justification for these rather frequent TCP > > keepalive messages when communicating with battery-powered devices. > > As in the PR vladikss linked: If the keepalive is set higher, it will > falsely tell users that the phone is connected when it is in fact not. The problem the desktop kdeconnect tries to solve with its uber-frequent TCP keep-alives is detecting whether the user mobile device is still connected or not. That's a genuine and common problem, and it has long been solved. The uber-frequent TCP keep-alives kdeconnect uses to solve this recurrent problem isn't the right solution or best practice, precisely because it drains mobile device battery. There are different solutions for this problem in different mobile OSs. kdeconnect authors should use those, instead of spamming those battery draining incessant TCP keep-alives. Numerous messenger apps solve this problem, none drains the battery as bad as kdeconnect does. > Please do the test as requested by vladikss. Without some evidence that a change actually makes a difference, it's just a random number. I am not the author, maintainer or QA of kdeconnect. That's why vladikss' request to expend my time and effort to do tests or experiments for him sounds rather wild to me. I have taken the time to provide an accurate description of the problem, root cause analysis and a working solution. That's the best I can do for kdeconnect. Conceptually, I have shown you the light. Whether to follow the light or stay in the dark is up to kdeconnect authors and maintainers. I don't care if they prefer staying in the dark.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!