Pinephone: reduce WiFi reconnection time after deep sleep

I'm not sure what will be difference in comparison to the udev rules from !1863 (closed) ? The udev rules now disable power saving as soon as the device is resumed right?

By Dylan Van Assche on 2021-02-15T19:35:14

The udev rules now disable power saving as soon as the device is resumed right?

Only if it is on a charger, not otherwise. This issue is about always disabling power management after suspend for a few seconds, so wifi can reconnect quickly, and then enabling power management again unless it's on charger.

By Oliver Smith on 2021-02-15T19:35:14

This seems really complicated.

Do we really save that much power with wifi powersave enabled? Maybe it should just be disabled all the time?

By clayton craft on 2021-02-17T19:27:42

Well, the difference between 1-1.5 days standby time and 2.5 - 3 days standby time...

Maybe:

WiFi turned ON? power save OFF
WiFi turned OFF? power save ON

By Dylan Van Assche on 2021-02-17T19:28:33

You measured this?

By clayton craft on 2021-02-17T19:29:31

Yes :) I have some measurements from debugging the power drain before Megi came up with a fixed powersave mode in the WiFi driver.

By Dylan Van Assche on 2021-02-17T19:31:39

How are you measuring 'standby time'? Is that with the device in suspend? Is the wifi device drawing more power in suspend with powersave disabled?

By clayton craft on 2021-02-17T19:36:42

Charge the device completely
Let it suspend
Every couple of hours, check the battery percentage
Do this with WiFi turned off and once with WiFi killswitched

With power saving, the same standby time is reached as WiFi killswitched. Without power saving, it drains a lot :( even if WiFi is turned off in the GUI.

By Dylan Van Assche on 2021-02-17T19:41:48

So we still want powersave enabled when entering suspend, then disable it when resuming for X seconds to allow for faster reconnect (then re-enable powersave if not on the charger). Is that right?

By clayton craft on 2021-02-17T19:44:22

Something like that... Maybe just:

enable when suspending
disable when resuming

?

Could be done with elogind

By Dylan Van Assche on 2021-02-17T19:45:23

Yeah, and still have the udev rule for enabling again when on battery?

By clayton craft on 2021-02-17T19:46:19

We could add in the suspend hook:

if on_battery:
  do X
else:
  do Y

By Dylan Van Assche on 2021-02-17T19:47:38

Right, so the whole hook could be something like:


case $1/$2 in
  pre/*)
    enable wifi powersave
    ;;
  post/*)
    disable powersave
    sleep 5
    if on_battery:
      enable powersave

And with the udev rule in !1863 (closed) powersave would be managed while not in suspend based on whether or not the charger is connected, like it does today.

@ollieparanoid would something like this work?

By clayton craft on 2021-02-17T19:51:45

Well, I was worrying about what happens when you get into suspend again during the sleep 5, that's why I proposed an extra program that handles this special case

But on second thought... that doesn't happen unless somebody runs loginctl suspend manually on the terminal in short succession. And even in that case, the worst case, the only thing that happens is, that after suspend it will enable power saving early and thus lead to the longer reconnection time. Not really a problem.

Let's do the simple solution

By Oliver Smith on 2021-02-17T22:06:26

I'm not sure if it's useful here, but elogind also supports post-suspend hooks: https://wiki.gentoo.org/wiki/Elogind#Hook_scripts_to_be_run_when_suspending.2Fhibernating_and.2For_when_resuming.2Fthawing

So this could be a simpler shell script instead of some standalone thing that depends on dbus/elogind binding, etc.

By clayton craft on 2021-02-17T19:43:00

(or maybe not, I just wanted to put that out here just in case. I don't really like the idea of having lots of specialized daemons running that might be harder to debug later on)

By clayton craft on 2021-02-17T19:45:27

True! The modem is a special thing, but this is much more simple...

By Dylan Van Assche on 2021-02-17T19:48:10

Fully agreed, let's do it with an elogind hook. @craftyguy, do you want to make the MR? (IIRC this has been annoying you a lot, so you would also be a good candidate to verify that this fixes it )

By Oliver Smith on 2021-02-17T22:07:45

Gladly! Yeah I'm super stoked that you figured out what caused it. I'll whip up something and make a MR for it.

By clayton craft on 2021-02-18T00:15:03

So this could be a simpler shell script instead of some standalone thing

+1 to this opinion. The whole existence of pinephone-specific "daemons" like eg25-manager (or proposed "wifi-power-manager") should be considered as a bug to be fixed, and is against design philosophy of postmarketOS ("Device specific code and configuration should be minimal.")

I don't want postmarketOS to become "Just another distro for PinePhone" like Mobian or worse, os full of quirks and "hacks" like Sailfish

By Alexey Min on 2021-02-18T00:41:19

mentioned in commit 55db4e0e

By clayton craft on 2021-02-18T00:32:48

mentioned in merge request !1965 (closed)

By clayton craft on 2021-02-18T00:33:45

mentioned in commit 6c629a0a

By clayton craft on 2021-02-18T00:35:06

mentioned in commit f958e7e5

By clayton craft on 2021-02-18T00:52:15

mentioned in commit e52eef0b

By clayton craft on 2021-02-18T00:56:43

mentioned in commit 67a6c836

By clayton craft on 2021-02-18T00:59:19

added device-pine64-pinephone label

changed the description

By Oliver Smith on 2021-09-29T19:05:18

mentioned in issue postmarketos#45 (closed)

By Oliver Smith on 2021-09-29T19:06:28

mentioned in issue pmbootstrap#1864 (closed)

By Oliver Smith on 2022-01-09T10:15:16

I ran iwd on the pinephone for a few months now (see https://gitlab.com/postmarketOS/postmarketos/-/issues/45#note_693145059), and noticed the following on postmarketOS edge:

at first it did not reconnect to wifi automatically at all after deep sleep (or it did attempt to and fail, and not try again, not sure). I'd have to select it manually. And even then I would have needed to select it multiple times, sometimes, until it succeeds.
however since a few weeks, it reliably reconnects after deep sleep, it's successful on first try (unlike networkmanager) and only takes... 5 seconds or so. I suspect a kernel or iwd upgrade fixed it?

For the people running pinephone + wpa_supplicant, did the situation improve there too, or is it still the same as when this issue was created?

See this issue for plans to roll out iwd in pmOS: #1379

By Oliver Smith on 2022-01-09T10:17:09

I have noticed the same improvement as @ollieparanoid although with wpa_supplicant (+ NetworkManager) since an upgrade I did in December that included upgrading the kernel package linux-postmarketos-allwinner from 5.13.1_git20210707-r1 -> 5.14.6_git20210920-r4, though I'm not sure if it was due to the kernel.

I think the actual underlying issue was that the WiFi connection duration was slow, independent of suspend. Before the upgrade, connecting to a WiFi network often was very slow (like a few dozen seconds or one minute, sometimes failing entirely). This was particularly noticeable after resuming from suspend, but also occurred when connecting to a network without suspending before. Now, connecting to a WiFi network often only takes a few seconds, including after resuming from suspend. It still sometimes occurs that connecting takes longer, but it seems the general issue is resolved now. It is now also much better at connecting to another network when I physically move the phone to another location where the signal of the old WiFi network is gone/weak (though it still takes a bit).

If anybody knows which component/commit fixed this issue, please tell me, I'm very interested because this issue had been bugging me for a while.

What still happens sometimes (at least with wpa_supplicant) is that the system does not try to connect at all to a known WiFi network, unless I open phosh's WiFi settings and manually initiate the connection. My intuition is that there is some kind of threshold how often a reconnection should be tried, and afterwards it does not try to connect automatically anymore. I'm not sure what software component would be responsible for that, NetworkManager or wpa_supplicant? Maybe there is some configuration option for that. I think a hard (re)connection count limit does not make much sense on a mobile device that you move around all the time.

#803 (closed) still occurs rarely, but it's not much of an issue and also sometimes happens on my laptop with another distribution, so it may be a more general issue not specific to the PinePhone or postmarketOS.

By pcworld on 2022-02-23T11:30:40

Is this still an issue? My PinePhone connects very quickly to wifi after waking up from suspend (less than a minute). And this is with wpa_supplicant, not iwd. In fact with iwd it takes five minutes or sometimes even longer, on both my PinePhone and my Surface RT, so I don't use it.

By Arnav Singh on 2024-03-17T14:15:26

My PinePhone still takes a noticeable amount of time to reconnect, at least a minute if not more, with both wpa_supplicant and iwd. It's certainly long enough that I now have a solitaire app on my PinePhone so I can play that while I sit around waiting for the WiFi to reconnect lol.

That is on 23.12 though, not sure if there are any changes on edge.

By Prajna Sariputra on 2024-03-17T14:15:26

Just got around to trying edge on my PinePhone, and it does look like reconnection after suspend is significantly faster now. With wpa_supplicant it seems to be able to manage 30s or less, while iwd can either be faster or just doesn't bother reconnecting (or at least I didn't bother waiting long enough). Even when iwd doesn't feel like reconnecting itself I can also do it manually sooner than I could with 23.12, so yeah it appears that this is at least way better on edge if not practically fixed.

The fact that Phosh now allows connecting to WiFi networks via its quick settings instead of having to open the Settings app is quite helpful for the manual reconnection case too.

By Prajna Sariputra on 2024-03-29T13:09:57

Good to know.

I should also mention I do use iwd on an OpenSUSE laptop since 2022, and it's slow to connect there too. So I don't think it's a PinePhone / Alpine / pmOS problem. And it interfaces with systemd-networkd there so I don't think it's a NetworkManager problem either.

It seems to me that iwd's problem is that insists on doing a full scan first and blocks connection attempts until that's done. Even if the desired network is the first one found by the scan (because the AP is two feet away from the device), it can take a long time for the scan if you're in an area with lots of other weak networks (apartment building in my case). I guess wpa_supplicant either reuses the previous scan, or it stops the scan when the target network is found, or some other optimization.

By Arnav Singh on 2024-03-29T16:01:38

Just switched back to 23.12 for comparison, and I'm starting to think that it was actually just my WiFi AP that didn't like the PinePhone or whatever during the time I was still using wpa_supplicant, back then wpa_supplicant would attempt to reconnect and then reach a 45s timeout as per the logs, then it gives up and disconnects, after which it would take more time to reconnect by itself. During that 45s period manually reconnecting, or even turning WiFi off and on again via Phosh didn't help. During that 45s period Phosh still thinks that there is a connection (the WiFi symbol on the status bar still looks connected), so I switched to iwd and stuck with that since it at least reported the connection status to NetworkManager/Phosh correctly, even if it still took time to reconnect.

Now however, after switching back to 23.12 both wpa_supplicant and iwd behaves the same as they did on edge, with wpa_supplicant being able to automatically reconnect faster than iwd. The WiFi AP I'm using isn't exactly a high end model (it's a TP-Link whatever supplied by the ISP), but none of my other devices have had much trouble with it (my laptop for example has an Intel AX200 WiFi adapter, and it reliably reconnects after suspend quickly enough that I don't have to think about it, and it uses NetworkManager plus wpa_supplicant).

TL;DR: My issue with slow reconnection using wpa_supplicant looks like a fluke, so I'd say this issue should be closed since there doesn't seem to be anything clearly actionable anyway.

By Prajna Sariputra on 2024-03-30T05:22:44

Some time ago, it was working better for my case. Now it went back to initial state (45s). I'd like to keep this open until we figure out why.

By Willow on 2024-03-30T07:01:03

added network::wlan label

Pinephone: reduce WiFi reconnection time after deep sleep

Child items 0

Activity