autotest: wifi_client: don't force-disable Wifi power-save mode |
||||
Issue description
Currently, all Wifi-related autotests will disable Wifi power-save mode before running. See:
server/cros/network/wifi_client.py WifiClient::__init__
# Turn off powersave mode by default.
self.powersave_switch(False)
This seems to have been done in 2013 here:
https://gerrit.chromium.org/gerrit/46537
commit 6866e09a5c03ad98eca832f30f8277b3bddb4eb6
Author: Christopher Wiley <wiley@chromium.org>
Date: Tue Mar 26 12:41:56 2013 -0700
autotest: Cleanup bad powersave state before network_WiFiMatFunc/007CheckPS
It claims that "we fail future test runs because power save remains on".
Previously, this might have been reasonable to do, as we left power-save disabled when plugged into AC, and only enabled power-save when on battery. Thus, there was some production use case of "power-save off", and therefore, measuring (for example) performance with power-save disabled is an understandable choice.
However, as of bug 689648 , we unconditionally enable Wifi power-save mode for all devices. IMO, this removes any argument that we should qualify our devices with power-save disabled -- if power-save is a source of bugs / unacceptable performance regressions / test failures, then it seems likely such bugs will hit real users. We're not doing anyone a favor by disabling this mode.
This bug should track the effort to re-enable power-save in our test environment. If there are any tests that fail today only when we enable power-save mode, we should investigate and fix them.
,
Aug 11 2017
Power save mode is enabled in CL: https://chromium-review.googlesource.com/c/604753/1. Tests that break, and their respective reports are 1) network_WiFi_GTK: crbug/740198 2) network_WiFi_DisconnectReason.ap_send_chan_switch: crbug/754909
,
Aug 15 2017
With the latest patch set + workarounds, this fails reliably on Kevin + Whirlwind, in network_WiFi_Regulatory: /tmp/test_that_results_hnRjsQ/results-1-network_WiFi_Regulatory/network_WiFi_Regulatory FAIL: Client never lost connectivity There are probably other failures. I think Satya noted some potential problems with that test already, so we should investigate whether we need to fixup or deprecate that test too.
,
Aug 15 2017
I also see failures here: /tmp/test_that_results_wR4whO/results-1-network_WiFi_BgscanBackoff.wifi_bgscan_backoff/network_WiFi_BgscanBackoff [ FAILED ] /tmp/test_that_results_wR4whO/results-1-network_WiFi_BgscanBackoff.wifi_bgscan_backoff/network_WiFi_BgscanBackoff FAIL: Significant difference in rtt due to bgscan: 531.6 > 8.8 + 200 On first blush, BgscanBackoff sounds like it could be a real problem with the DUT. Is it reasonable to get these results with background scan: 08/15 17:20:37.114 DEBUG| utils:0280| [stdout] 1000 packets transmitted, 999 received, 0% packet loss, time 100548ms 08/15 17:20:37.114 DEBUG| utils:0280| [stdout] rtt min/avg/max/mdev = 1.629/12.820/531.551/33.750 ms, pipe 6 vs. these without: 08/15 17:21:09.250 DEBUG| utils:0280| [stdout] 100 packets transmitted, 100 received, 0% packet loss, time 9942ms 08/15 17:21:09.250 DEBUG| utils:0280| [stdout] rtt min/avg/max/mdev = 2.620/8.803/10.893/1.156 ms ? The test seems repeatable too.
,
Aug 17 2017
Filed this for Kevin/Marvell 8997 issues with network_WiFi_BgscanBackoff: https://issuetracker.google.com/64771701
,
Aug 20
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 20
|
||||
►
Sign in to add a comment |
||||
Comment 1 by briannorris@chromium.org
, Jun 20 2017Status: Assigned (was: Available)