New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 759217 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Background scans should be disabled on outgoing traffic / Investigate throughput dip in long running iperf tests

Project Member Reported by kirtika@google.com, Aug 25 2017

Issue description

OS: R60-R62

Filing this based on go/eve-iperfthroughput.
RF team ran some long iperf tests and found we dip to 0.0 mbps and dont scale up the rate
fast enough after that, at some intervals (perhaps once every 15-25seconds). 
This seems to be a background scan. But we have a test -  network_WiFi_BgscanBackoff that checks for a background scan being aborted when there is outgoing traffic.
This bug tracks checking: 
(a) does this dip to 0.0 mbps happen only on incoming traffic? (no, seem on upload as well). 
(b) is it a background scan or something else that is causing this? 
(c) if (b) is yes, fix it and add a test/modify network_WiFI_BgscanBackoff as needed. 
(d) Initial data hinted that this could be a SW regression, however, I do see in R60 through R62..


 
Do we aim for background scans to be *disabled* completely during TX? The test only measures for unacceptable drops in latency, which seems reasonable. But I also wouldn't want Wifi to be completely wedged just because some app/webpage is trying to TX data (i.e., TX shouldn't be able to completely starve scans, should it?). We would need scan information to determine that the current BSS signal is too low and that we have reasonable alternatives.

I believe some drivers already try to balance this by reducing the bandwidth of their scans when associated, for example, by breaking them up into smaller regions that they schedule less frequently. I don't know what the timing and performance implications of these kind of things are though, and whether they can be optimized more.

Comment 2 Deleted

Comment 3 Deleted

Comment 4 by yoshi@chromium.org, Jan 3 2018

Cc: -yoshi@chromium.org
Status: Assigned (was: Untriaged)

Sign in to add a comment