Does this only happen when bluetooth scanning is happening or when bluetooth is enabled in general? 

Are you using 2.4 or 5 GHz? 

The user claims it's when Bluetooth is on in general and they're using 2.4Ghz. 

We'll try to repro from our side.

Attached screenshots of  our speed test observations on mickey 10032.25.0 build

Deleted: Screenshot 2017-11-02 at 12.05.04 PM.png 1.2 MB

	Screenshot 2017-11-02 at 12.05.04 PM.png 1.2 MB View Download

Deleted: Screenshot 2017-11-02 at 12.05.54 PM.png 1.2 MB

	Screenshot 2017-11-02 at 12.05.54 PM.png 1.2 MB View Download

(Ha, thanks at #6! I was literally just going to ask if we tested without the scanning UI activated)

We should probably run a proper coexistence test (does anybody use network_WiFi_BluetoothStreamPerf? or network_WiFi_BluetoothScanPerf?), and then see if there's anything we can get Broadcom to do about this...

cc'ing Aashutosh who also works on wifi testing.

So mickey was a super challenging device in terms of BT and WiFi.  On earlier HW / SW builds of Mickey WiFi worked OK but BT would only work if the BT device was a few centimeters from the device.  :(

You can search for Proj-Mickey and bluetooth on the internal bug tracker and find a whole lot of details about this type of stuff (sorry, not public!).

My understanding is that, in the end, they came up with something that was pretty good.  The end of b/35559415 says:

> Tested mickey on M46-7390.61.0 in an OTA (over-the-air) wificell. 
> 
> WiFi functional tests have not regressed. Test failures are KI (example: crosbug.com/p/27486). 
> 
> Checking the TCP RX/TX throughput speeds for the following configurations, there were also no WiFi performance regressions. 

So at least someone at some point in time thought that everything was OK...


It's certainly possible that something in the software changed.  It's also possible that there is some bad hardware out there...


For @5 and @6, it's super important that you're doing your testing on something close to final hardware and also that you're doing testing on something that hasn't ever been opened for rework.  A lot of these things changed pretty late in the game, so if you're testing on EVT or DVT you might be seeing issue that were later resolved.

Certainly if you've got a device that's been modified to have a servo header then I wouldn't necessarily trust it right away, which makes it hard to automate testing.  :(


I think I've got something close to final hardware at my desk if you want to borrow it tomorrow.

-Doug

> A lot of these things changed pretty late in the game, so if you're testing on EVT or DVT you might be seeing issue that were later resolved.

I'd like to call out that my customer has replaced their MP unit with ASUS and the issue persisted on the replacement. 

Miao: are you the right owner for this?

I am also reaching out to my Asus counter part to check this on their end.

OK, so it sounds as if there's not too much we can do here.  Bluetooth and WiFi both work at 2.4 GHz so inherently this is a difficult problem.  Mickey's small size makes this even more of a challenge.  I heard a rumor (but can't personally confirm) that other similar form factor devices have similar problems when trying to simultaneously use Bluetooth and 2.4 GHz WiFi.

While I can't say that it's impossible to make this work better, it seems as if we've already done all the tuning that we were able to do.  That means that your options are to either use 5 GHz, accept the slightly slower WiFi speeds, or avoid using Bluetooth.

Sorry for the bad news...