flicker-free suspend/resume on Intel

Posted Mar 7, 2013 13:12 UTC (Thu) by sebas (guest, #51660)
In reply to: flicker-free suspend/resume on Intel by sebas
Parent article: The conclusion of the 3.9 merge window

Thanks all for the answers, that's exactly what I wanted to know.

Looking forward to flicker-free suspend/resume. Because I do that approximately a 100 times more often than rebooting, so not sure why everybody cares so much about flicker-free boot, with suspend states working stable and fast.I also hope to get a nice speedup from this, as the vt switch takes a long time here and is quite blocking.

Now if I only could convince networkmanager to not drop the wifi connection purposefully, on suspend/resume, because that's apparently not necessary anymore with this nice ultrabook hardware. Using ifup/ifdown, it does not and is immediately online. Did anybody try that?

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 14:03 UTC (Thu) by johill (subscriber, #25196) [Link] (8 responses)

The "immediately" online behaviour isn't really immediate, you will typically have been disconnected from the AP. In fact, this disconnection is now going to be enforced for 3.10 because the other behaviour doesn't gain a whole lot (you still need to reconnect etc.) and trying to keep the connection causes a huge amount of issues, particularly with USB hardware (that can be unplugged while suspended.)

The "ultrabook" behaviour you refer to can be achieved with WoWLAN (http://wireless.kernel.org/en/users/Documentation/WoWLAN) and network scanning offload (while in suspend), but this doesn't exist in Linux yet.

However, a much easier solution could be implemented in NetworkManager: instead of scanning on all channels when resuming, it could scan just the channel that it was previously connected on. If that finds the previously connected AP, it would be able to reconnect almost immediately (delay of less than half a second), vs. a full scan that can take up to 10-15 seconds. This should be a fairly simple NetworkManager change.

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 17:18 UTC (Thu) by raven667 (subscriber, #5198) [Link] (7 responses)

It's also not as if this kind of problem is unique to Linux or NetworkManager, I experience very similar behavior on my MacOSX laptop when resuming from suspend, so this is a common problem with wireless. The stated solution probably won't speed up connection when changing location but keeping the same SSID as you will likely be connecting to a different AP on a different channel and it'll have to scan anyway.

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 20:39 UTC (Thu) by johill (subscriber, #25196) [Link] (2 responses)

Well, yes. Although you could scan the channels in the right order, i.e. the ones that you'd expect the same network (SSID) on first. Say your corporate installation -- it's probably only going to use a handful of channels (1,6,11,36,149 or so), so if you know from "experience" that (almost) all of the APs for the network are there, you can scan those first.

But ultimately you're right, in the general case you have to scan all channels and that simply takes a while. It shouldn't be more than a few seconds since you're not connected; here it takes ~3.5 seconds to scan all the channels my card supports, but I know that it can be (much) slower depending on the device.

flicker-free suspend/resume on Intel

Posted Mar 7, 2013 23:25 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

well, you should first check the channel you were last using, and then do the normal scan you would do if someone just gave the SSID and told you to connect to it.

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 0:10 UTC (Fri) by johill (subscriber, #25196) [Link]

Yeah, that's what I suggested first (and indeed Dan has now opened a bug for to implement it in NM), however it is possible to break it down further like I was trying to describe later:

1) scan the last channel
2) scan the known channels for the last SSID
3) scan all (remaining) channels

The intermediate step only makes sense if those known channels are a relatively small subset of all channels, but with typical installations they will be. In fact, for many networks like your home network 1) and 2) will be exactly the same because you only have a single AP, but for typical enterprise networks 2) will still be better than 3).

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 0:56 UTC (Fri) by mgedmin (subscriber, #34497) [Link] (3 responses)

Somewhat tangentially there's a very interesting article about DHCP tricks that MacOS X does to reconnect faster.

I'd love to see Network Manager pick up something from that.

Instead, currently when I suspend a laptop via ssh -t foo sudo pm-suspend, I get to enjoy a lapsed DHCP lease on resume, for a few hours. According to strace that's because dhcpd expiration timer (i.e. select() with a timeout) simply stops while the laptop is suspended. Connection still works, but the wifi router doesn't resolve the laptop's hostname until dhcpd finally wakes up.

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 9:07 UTC (Fri) by johill (subscriber, #25196) [Link]

This would be easier in connman as it has DHCP built into it rather than calling out to dhclient (running as a daemon)

flicker-free suspend/resume on Intel

Posted Mar 8, 2013 15:35 UTC (Fri) by njwhite (guest, #51848) [Link]

Ah, I've run into this with wpa_supplicant on Debian. Have you found a solution to it? Is there a straightforward way to get dhclient to wake up when the computer resumes?

flicker-free suspend/resume on Intel

Posted Mar 14, 2013 0:46 UTC (Thu) by kevinm (guest, #69913) [Link]

If CLOCK_MONOTONIC in Linux actually worked according to POSIX spec, then a timer based on this clock could be used to fix this problem.

(POSIX says that CLOCK_MONOTONIC measures time elapsed since "an unspecified point in the past", and further "This point does not change after system start-up time.". On Linux however, CLOCK_MONOTONIC stops while the system is suspended, which is clearly nonconforming).