Fix incorrect phy mode in hostapd_config : it leads to misreporting in wifi_perf & other tests |
|||
Issue description
hostapd_config.py in autotests has the below code snippet (see [1]).
Tracking the git history of this snippet is a bit tricky as the file was moved around.
I do not understand why we would want to report 11A or 11G when we are really on 11N or 11AC. The returning 11G by default somewhat makes sense given that traditionally hostapd_config inits with a default 11 G config (a CL to change that is at [2]).
Why is this problematic? It confuses wifi developers and whoever else these test results are sent to (e.g. rf engineers). I sent the results in [3] to someone and they came back with a response that included "Another finding is that the test mode is listed as "mode11a", which seems to be a legacy rate with only 20 MHz support."
[1]
if self._is_11n or self.is_11ac:
# For their own historical reasons, hostapd wants it this way.
if self._frequency > 5000:
return self.MODE_11A
return self.MODE_11G
raise error.TestFail('Invalid mode.')
[2] https://chromium-review.googlesource.com/#/c/chromiumos/third_party/autotest/+/720102/
[3]
[##] Results from the latest build on Eve
ch044_mode11A_none_PSon_signal{perf}=-22
ch044_mode11A_none_PSon_tcp_tx_throughput{perf}=168.21+-1.35
ch044_mode11A_none_PSon_tcp_rx_throughput{perf}=248.53+-40.12
ch044_mode11A_none_PSon_udp_tx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSon_udp_tx_throughput{perf}=210.39+-1.14
ch044_mode11A_none_PSon_udp_rx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSon_udp_rx_throughput{perf}=230.06+-1.67
ch044_mode11A_none_PSoff_signal{perf}=-22
ch044_mode11A_none_PSoff_tcp_tx_throughput{perf}=180.28+-0.78
ch044_mode11A_none_PSoff_tcp_rx_throughput{perf}=271.33+-32.77
ch044_mode11A_none_PSoff_udp_tx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSoff_udp_tx_throughput{perf}=210.52+-1.30
ch044_mode11A_none_PSoff_udp_rx_errors{perf}=0.00+-0.00
ch044_mode11A_none_PSoff_udp_rx_throughput{perf}=329.95+-1.61
ch157_mode11A_none_PSon_signal{perf}=-24
ch157_mode11A_none_PSon_tcp_tx_throughput{perf}=168.23+-0.23
ch157_mode11A_none_PSon_tcp_rx_throughput{perf}=256.94+-24.61
ch157_mode11A_none_PSon_udp_tx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSon_udp_tx_throughput{perf}=210.24+-1.28
ch157_mode11A_none_PSon_udp_rx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSon_udp_rx_throughput{perf}=225.44+-0.70
ch157_mode11A_none_PSoff_signal{perf}=-24
ch157_mode11A_none_PSoff_tcp_tx_throughput{perf}=179.05+-1.33
ch157_mode11A_none_PSoff_tcp_rx_throughput{perf}=258.94+-30.15
ch157_mode11A_none_PSoff_udp_tx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSoff_udp_tx_throughput{perf}=209.67+-2.33
ch157_mode11A_none_PSoff_udp_rx_errors{perf}=0.00+-0.00
ch157_mode11A_none_PSoff_udp_rx_throughput{perf}=323.56+-0.85
,
Jan 19 2018
,
Apr 16 2018
I'm fixing the labeling here, so at least perf results won't get aliased between 11A and 11AC: https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1013261 This doesn't fix the problems with configuring the packet capture mode (ht_packet_capture_mode) -- so beware any tests that think they're configuring a packet capture for VHT80 rates. For example, I see that depending on the circumstances [1], network_WiFi_SimpleConnect.wifi_check5VHT80 might try to configure the capture device for non-VHT rates, like this: 04/12 19:59:13.297 DEBUG| ssh_host:0301| Running (ssh) '/usr/local/sbin/iw dev monitor0 set freq 5180' from '_call_run_once|run_once|start_capture|configure_raw_monitor|run|run_very_slowly' https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/191594077-chromeos-test/chromeos15-row1-rack1-host2/network_WiFi_SimpleConnect.wifi_check5VHT80 I see the resulting pcap doesn't actually capture the data packets properly -- it mostly just captures the management frames. This isn't immediately critical, but it would be a problem if we start relying on the packet capture file for tests in this mode. I'll take this for now. [1] See this code, which may or may not try to reconfigure the wiphy frequency band: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/49083c3c5a8a34595222c2009881b175b03422b8/server/site_linux_system.py#320 # If this is the only interface on this phy, we ought to configure # the phy with a channel and ht_type. Otherwise, inherit the settings # of the phy as they stand.
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/autotest/+/860ad5164a6e1e11f4ec99a1c05ae7e021384d00 commit 860ad5164a6e1e11f4ec99a1c05ae7e021384d00 Author: Brian Norris <briannorris@chromium.org> Date: Tue Apr 17 22:53:11 2018 network_WiFi_Perf: log VHT80 correctly in keyval results Wifi perf results generate keys by using the hostap config's printable_mode() method. This method didn't handle VHT80 correctly and instead interpreted it as 11A. Add special handling for VHT. I don't currently plumb the corresponding packet_capturer parameters, because (a) our current 'iw' doesn't have a clear way of configuring this (or at least, I was too lazy for this at the moment) and (b) we should probably plumb packet capture modes (i.e., 'iw dev XXX set freq ...') differently than "printable mode" anyway. Note that this means we probably aren't capturing network_WiFi_SimpleConnect.wifi_check5VHT80 correctly. Fortunately, that's the only other test that uses VHT rates, and it doesn't actually utilize those captures for anything. BUG=chromium:827829, chromium:774831 TEST=network_WiFi_Perf.vht80 (and others); check that the results/keyval file contains results like: ch044_modeVHT80_none_PSon_tcp_tx_throughput{perf}=191.98+-0.56 instead of: ch044_mode11A_none_PSon_tcp_tx_throughput{perf}=193.73+-5.60 Change-Id: I038eeeb1a54998324458ffe9609b6ea06d4766f2 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1013261 [modify] https://crrev.com/860ad5164a6e1e11f4ec99a1c05ae7e021384d00/server/cros/network/hostap_config.py |
|||
►
Sign in to add a comment |
|||
Comment 1 by ovanieva@google.com
, Jan 19 2018