Closed Bug 1156787 Opened 5 years ago Closed 4 years ago

Telemetry probe for wifi ap count (suspected problem on win xp)

Categories

(Core :: DOM: Geolocation, defect)

31 Branch
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: garvan, Assigned: garvan)

References

Details

Attachments

(1 file, 1 obsolete file)

Existing telemetry for GEOLOCATION_ACCURACY indicates on windows 5.1/5.2 there may be problems getting a wifi scan. Accuracies of a few hundred meters or less require a wifi scan.

For instance looking at release 36, 
- windows 5.1 showing is ~5% wifi-level-accuracy:http://mzl.la/1bpfR5x
- and windows 5.2 showing zero wifi-level accuracy: http://mzl.la/1K22dki

In this case however, 5.2 only has 333 submissions and 5.1 has 28K, so the sample rate isn't large enough.

Here is Beta 38, with 6K submissions, showing zero wifi-level accuracy:
- http://mzl.la/1bpgR9K

Release 37, with 6K submissions, showing ~5% wifi-level accuracy:
- http://mzl.la/1bpiG6D

The only clear pattern is that release builds look ok, but I couldn't explain why that would be the case. I would suspect that pre-release builds would show a greater rate of wifi scans, in that those users would be more likely to have laptops, and release users would be on legacy desktop hardware.
Attached patch add wifi ap telemetry probe (obsolete) — Splinter Review
Attachment #8595366 - Flags: review?(cpeterson)
I forgot to mention, >0% reports of wifi-level accuracy would be ok, we aren't looking for a specific value.
Comment on attachment 8595366 [details] [diff] [review]
add wifi ap telemetry probe

With n_buckets=10, high=20 - can we clearly distinguish between the 0, 1 and 2 buckets? Or does it merge 1 and 2 together into a single bucket?

Since the service only answers queries with 2+ found wifi networks, I'd be interested to see clear stats on the 0, 1 and 2 buckets each on their own.
Lets not risk it, agreed 0,1,2,3 are the most important, buckets=10, high=10 it is
Attachment #8595366 - Attachment is obsolete: true
Attachment #8595366 - Flags: review?(cpeterson)
Attachment #8595376 - Flags: review?(cpeterson)
Attachment #8595376 - Flags: feedback+
Comment on attachment 8595376 [details] [diff] [review]
wifi_ap_telemetry.diff

Review of attachment 8595376 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM with some questions. What question are you trying to answer with this new telemetry probe? Whether Windows 5.1 and 5.2 users get inaccurate results because they are have no Wi-Fi? If that answer is yes or no, what action can we take?

::: dom/system/NetworkGeolocationProvider.js
@@ +395,5 @@
>        return { 'macAddress': ap.mac, 'signalStrength': ap.signal };
>      };
>  
>      let wifiData = null;
>      if (accessPoints) {

If accessPoints is null, do we want to report GEOLOCATION_WIFI_APS_VISIBLE == 0?

@@ +397,5 @@
>  
>      let wifiData = null;
>      if (accessPoints) {
>        wifiData = accessPoints.filter(isPublic).sort(sort).map(encode);
> +      Services.telemetry.getHistogramById("GEOLOCATION_WIFI_APS_VISIBLE").add(wifiData.length);

If histogram's high == 0, what happens when we report wifiData.length > 9? Do we need to clamp at 9 access points?
Attachment #8595376 - Flags: review?(cpeterson) → review+
Thanks Chris!

> LGTM with some questions. What question are you trying to answer with this
> new telemetry probe?

Looking for clues as to whether there is a bug here, or if this is all normal variances in telemetry data. 
Are XP users scanning 1-2 APs (which is too few for a query). Are XP users scanning at all? Are these numbers completely different than we expect and there is a different bug entirely (for instance, what if we are seeing a large percentage of XP users actually have wifi scans reported of 10+ APs, what *then* is the bug?).

In all likelyhood, we will see that a small number of users are getting wifi scans, which means a small number of users *have* wifi, and this will correlate with the small number of users we see getting wifi-level accuracy.

> Whether Windows 5.1 and 5.2 users get inaccurate
> results because they are have no Wi-Fi? 

This is one piece of that puzzle, but not definitive. Ideally, we would check 1) are they connected to wifi, and 2) can they scan wifi. We are answering 2 without 1. I should look and see if we can get info on the type of network connection. 

> If that answer is yes or no, what action can we take?

1) Determine if there is a bug here, and get one filed. 2) Determine it is worthwhile to commit time to setting up an XP dev environment to properly repro and debug what is happening.
Mostly just (1).

> 
> ::: dom/system/NetworkGeolocationProvider.js
> @@ +395,5 @@
> >        return { 'macAddress': ap.mac, 'signalStrength': ap.signal };
> >      };
> >  
> >      let wifiData = null;
> >      if (accessPoints) {
> 
> If accessPoints is null, do we want to report GEOLOCATION_WIFI_APS_VISIBLE
> == 0?

I would only want to report on this if the current connection was known to be wifi. (I need to see if I can determine that).
At least I don't know what I would conclude from gathering that info on its own, suggestions welcome though.

> @@ +397,5 @@
> >  
> >      let wifiData = null;
> >      if (accessPoints) {
> >        wifiData = accessPoints.filter(isPublic).sort(sort).map(encode);
> > +      Services.telemetry.getHistogramById("GEOLOCATION_WIFI_APS_VISIBLE").add(wifiData.length);
> 
> If histogram's high == 0, what happens when we report wifiData.length > 9?
> Do we need to clamp at 9 access points?

Doesn't it all just go into the highest bucket: the 10 bucket? We don't _need_ to clamp at 10, but I like the histograms to be easy to read at glance, and 10 and above fits into the mental category of "has lots of wifis, is good candidate for wifi geolocation". 
Arguably, this could be enumerated to:
1 wifi: if we see a ton of this, there is a bug in XP scanning code, where only the active wifi is being shown
2 wifis: not enough wifi to send; if a peak here, this is suspicious, why is there only 2 being shown? Unfortunately the scanning isn't clearly broken as in the above, so we would have to investigate deeper.
3-9: scanning works. Maybe just aren't seeing enough wifis that wifi lookups are possible
10+: scanning works, good likelihood of wifi location lookup.
Blocks: 1157400
Leaving this aside for now, bug 1157400 describes how XP wifi scanning is broken ATM.
Closing, confirmed it doesn't work on XP, and fixed in bug 1157400
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.