Chromium Code Reviews
Help | Chromium Project | Gerrit Changes | Sign in
(13)

Issue 3553003: Reduce reacquire timers so that full scan happens sooner after resume from suspend (Closed)

Created:
8 years, 8 months ago by Paul Stewart
Modified:
8 years, 1 month ago
Reviewers:
Sam Leffler
CC:
chromium-os-reviews_chromium.org, Mandeep Singh Baines, sleffler+cc_chromium.org, Olof Johansson, vb
Base URL:
ssh://gitrw.chromium.org/kernel.git
Visibility:
Public.

Description

Reduce reacquire timers so that full scan happens sooner after resume from suspend This modification reduces the re-acquisition time for access points when the system goes to sleep in one environment and wakes up in a different one. The default Linux kernel parameters spend way too long retrying the current AP. This change modestly tunes down these parameters. I did tests to make sure that in a normal suspend case we re-find our AP, and did empirical tests to confirm that we gain 2 seconds on average with this change. BUG=none TEST=Test parameters: - Running in WiFi testbed using prototype hardware - ./bin/cros_run_wifi_tests.sh --cell=5 -a "test_pat=002*" Roaming - This runs network_WiFiRoaming/network_WiFiRoaming.002Suspend - The "wait_service_suspend_end_ready" result gives a fairly accurate figure of how long it took for the DUT to reacquire the access point after returning from suspend and finding out that it has switched channels. With TOT build, the results are, after 5 runs: 15.943 15.616 15.616 15.847 15.89 With modification of kernel to reduce number of probes and reduce time waiting for probe responses: 13.924 13.416 13.51 13.909 13.915 Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=739f16b

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+2 lines, -2 lines) Patch
M chromeos/compat-wireless/net/mac80211/mlme.c View 2 chunks +2 lines, -2 lines 0 comments Download

Messages

Total messages: 2 (0 generated)
Paul Stewart
8 years, 8 months ago (2010-09-30 00:03:21 UTC) #1
Sam Leffler
8 years, 8 months ago (2010-10-01 16:31:45 UTC) #2
As we've discussed we should instead use ACK/!ACK of 1 ProbeReq frame as that's
on the order of 120us (assuming max 7 rexmit's and normal ACK timeout) instead
of the current 2.5s or 400ms w/ your tweaks.  But given that involves
significantly more work I'll LGTM this.

If it's easy you might make this a compile-time tunable before pushing.

Powered by Google App Engine
This is Rietveld 408576698