Re: long delay for scan results after suspend
On Tue, 2009-12-29 at 12:41 +, Daniel Drake wrote: > On Thu, 2009-12-10 at 16:22 +, Daniel Drake wrote: > > With the new OLPC XO-1.5, our kernel driver fully powers down the > > wireless device during suspend to the point where the kernel thinks the > > SDIO card has been ejected. > > > > It immediately comes back on resume, but there is a delay of > > approximately 20 seconds before NM offers scan results to Sugar, which > > is frustratingly long. > > The delay isn't quite so severe, at least for me. I think we may have > been seeing other problems. > > However, we do still face a 4-5 second delay due to constructor() in > nm-device.c: > > /* Delay transition from UNMANAGED to UNAVAILABLE until we've given the >* system settings service a chance to figure out whether the device is >* managed or not. >*/ > priv->start_timer = g_timeout_add_seconds (4, device_start, dev); The comment should be pretty self-explanatory here; basically we need to give some time for the system settings service to call out to HAL or whatever and determine that the device should be managed. NM can't block on that because unmanaged devices is a property so that changed signals can be emitted. > Can we do better than that? For an aggressive-suspend setup like ours, > having to wait this long for networks to crop up again is quite harmful > to the user experience. Not without risking race conditions and mismanaging devices that shouldn't be managed, no... > And just out of curiosity, is this any better in 0.8? I can see that the > code has moved around quite a bit. It is no longer a problem in 0.8 now that the system settings service has been moved into NM itself. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: long delay for scan results after suspend
On Thu, 2009-12-10 at 16:22 +, Daniel Drake wrote: > With the new OLPC XO-1.5, our kernel driver fully powers down the > wireless device during suspend to the point where the kernel thinks the > SDIO card has been ejected. > > It immediately comes back on resume, but there is a delay of > approximately 20 seconds before NM offers scan results to Sugar, which > is frustratingly long. The delay isn't quite so severe, at least for me. I think we may have been seeing other problems. However, we do still face a 4-5 second delay due to constructor() in nm-device.c: /* Delay transition from UNMANAGED to UNAVAILABLE until we've given the * system settings service a chance to figure out whether the device is * managed or not. */ priv->start_timer = g_timeout_add_seconds (4, device_start, dev); Can we do better than that? For an aggressive-suspend setup like ours, having to wait this long for networks to crop up again is quite harmful to the user experience. And just out of curiosity, is this any better in 0.8? I can see that the code has moved around quite a bit. Thanks, Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: long delay for scan results after suspend
On Thu, 2009-12-10 at 16:22 +, Daniel Drake wrote: > Hi, > > With the new OLPC XO-1.5, our kernel driver fully powers down the > wireless device during suspend to the point where the kernel thinks the > SDIO card has been ejected. > > It immediately comes back on resume, but there is a delay of > approximately 20 seconds before NM offers scan results to Sugar, which > is frustratingly long. > > When is NM expected to perform scans in this situation? First thing to check is if the driver is failing the scan with -EBUSY or something like that. If it is, unfortunately wpa_supplicant doesn't have a way to get that failure back to NetworkManager due to the way that the supplicant is structured; the D-Bus call just schedules a scan request and returns; there's no way to track the D-Bus call through the scan request and return success/fail when the scan request actually gets executed. But if the request fails, the supplicant will schedule another scan for 10 seconds later, so if the driver does fail the first scan, you're looking at that 10-second backoff + 2 - 5 seconds of scan time, plus latency in pushing the results from kernel -> supplciant -> NM -> sugar (which won't be much but still noticable). There are two ways to tackle the issue; (a) make sure the driver is ready faster, or (b) make wpa_supplicant more intelligent about the reasons for scan request failure and make it try again sooner depending on the driver's returned error code. I'd actually do both; (b) is required anyway since some drivers seem to return EBUSY a lot (ath5k) and thus make for very poor user experience. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
long delay for scan results after suspend
Hi, With the new OLPC XO-1.5, our kernel driver fully powers down the wireless device during suspend to the point where the kernel thinks the SDIO card has been ejected. It immediately comes back on resume, but there is a delay of approximately 20 seconds before NM offers scan results to Sugar, which is frustratingly long. When is NM expected to perform scans in this situation? It is possible that the libertas wifi driver is taking this long to deliver results although it seems unlikely. Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
