[jancsika]

The feature set commenters here want is insane:

* fast as possible

* LAN, but also WAN when necessary

* in fact how about multi-protocol, and use the fastest protocol that's available on both devices, it's 2025 people!

* work for sending a gargantuan amount of files with possible interruptions (essentially, be rsync)

* be battery efficient, it's 2025 people!

* don't rely on a centralized cloud server, just connect the damned devices to each other

If you think you can hack this together, you should write it for Gnu Hurd because they'll release that well before you're finished

[ValdikSS]

>* be battery efficient, it's 2025 people!

It took a long time for me to prove that what KDE does negatively impact the battery life.

https://bugs.kde.org/show_bug.cgi?id=441830

The other user even wrote a LD_PRELOAD hijacking library to not recompile the application every time

https://github.com/max0x7ba/kdeconnect-powersave-keepalive

[ndriscoll]

A 5 second keepalive seems unnecessary, but does that actually impact battery life? How long does the device take to move in and out of powersave states? I'd think you'd be looking at maybe 20-40 microseconds of CPU time to handle the packet, so 0.0008% of the time awake due to this. Are other parts of the device just super slow at moving in and out of powersave states?

[ValdikSS]

Yes, it has dramatic impact on the battery life.

Wi-Fi in lower power state, when it has nothing to respond to, disables power amplifier and only listens to incoming data. Some functions which are usually performed by the OS are offloaded on smartphones to the Wi-Fi chip, such as ARP/NDP replies, so it doesn't need to wake up a CPU to perform simple answers.

However with the constant keep-alive it has to both enable power amplifier and to wake up the CPU to send the reply that the socket is still alive.

I have a single-board computer with and old Mediatek chip (10 years old), and there Wi-Fi PA increases power consumption by 200mW. Another reporter in the ticket told that his smartphone works basically 1/2 of its common battery life with KDE Connect enabled.

Keep-alives (not necessary TCP keep alives, but any of this kind of packets) are the _MAIN_ reason for internet battery drain while idle, and are tricky to debug if you don't know where to look (Android lists it as "Android System" or "Phone Idle")

For example, Golang applications had 15 second keep alive until recently: https://github.com/golang/go/issues/48622. Imagine you've opened the website which uses golang web server/proxy and enabled notifications from it in the browser, which use WebSocket from the website itself. Now every time your CPU is woke up every 15 seconds until you close the page and notification channel is offloaded to google/mozilla servers. And remember: every TCP connection has its own 15-second Keep-Alive in different intervals, so it's more like 5-7 second CPU wakeup interval.

The same applies for VPN. When anybody say that anways-on VPN connection drains battery, that is 90% if the time is due to frequent keep-alive packets from the VPN server.

Everything above applies to cellular connection as well, it's the same principle.

[j1elo]

> It took a long time for me to prove that what KDE does negatively impact the battery life. https://bugs.kde.org/show_bug.cgi?id=441830

Status: RESOLVED

> 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.

This trend of auto-closing issues is so upsetting. Can we get rid of it already? This describes an actual issue, and it wouldn't get magically resolved through a lack of actions. I could maybe buy auto-closing bugs that have been stale for 3 years, but 30 days is just ridiculously short. It only serves as makeup for the numbers to appear as if there are not many defects in the software, and it seems to be a common practice in too many projects.

---- EDIT: Turns out this got fixed in the end [1]. Good for this particular case, but the point stands.

[1]: https://invent.kde.org/network/kdeconnect-kde/-/merge_reques...

[snthd]

Fixed in "Remove custom keepalive intervals" merged 12 Aug 2024

https://invent.kde.org/network/kdeconnect-kde/-/merge_reques...

[ValdikSS]

It improved the battery life but made the connection activity detection worse (the disconnected phone won't be detected for up to 2 hours), but I didn't complain anymore.

I initially set it to 5 minutes.