Closed Bug 1806942 Opened 1 year ago Closed 1 year ago

high, varying ping after doing Google search

Categories

(Core :: Networking: HTTP, defect, P3)

Firefox 108
x86_64
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1810421
Performance Impact ?

People

(Reporter: michael, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

To reproduce:

  1. Run Path of Exile. Show the latency tracker with F1. Observe the ping being low and steady (20ms for me).
  2. Open Firefox. Load any Google Search page (ctrl-k "report Firefox bug" was what I used to confirm).
  3. Look at the latency chart.

Latency is now spiking up to over 100ms every 6 seconds for about 1 second, and then go back down to the previous steady state. Closing Firefox is the only way I've found to fix this. With Firefox closed, the latency goes back to normal.

I have tested this in Firefox Troubleshoot Mode, i.e. with no extensions or other settings changed from the default. I have also confirmed that there is no excessive network activity - sub-100kB/sec from the host as a whole, and even less from Firefox. when I can easily push over 100Mbps on this connection. I have also confirmed that I can see the latency change with other applications, like commandline ping or https://packetlosstest.com/. I've run the linked WebRTC packet loss/latency test both in the same Firefox instance that is causing the issue and in Chrome.

I have also tested latency from other hosts on my network and haven't seen increased latency on them, which makes me think that this is local interference and not something in some way messing with my network equipment.

I've found a number of similar reports on forums like Reddit, but nothing in this bug tracker so far.

I have not yet tested on platforms other than Windows 10.

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Blocks: necko-perf
Severity: -- → S4
Priority: -- → P3
Whiteboard: [necko-triaged]

This is reproducible without running a third-party program, just within Firefox. I've also been finding that the repro isn't 100% - it does not work every time. However, the state does get reached every time I use Firefox, it just might take a bit.

  1. Open Firefox. Browse for a while.
  2. Create a latency chart using https://packetlosstest.com/ in either Firefox or a second browser. Note the latency spiking periodically.

I disagree with the S4 severity choice as I am going to switch browsers because of this issue, since I haven't been able to find any sort of mitigation. This is not a cosmetic, low-impact issue - it's an issue that makes me close Firefox several times per day when I try to use it. That would put the severity at S2, according to https://firefox-source-docs.mozilla.org/bug-mgmt/guides/severity.html.

I'm on MacOS, using https://packetlosstest.com/ I haven't reproduced a noticeable spike in Firefox (comparing against Chrome and Safari).

If you can share more evidence of the latency spikes in Firefox, please do so.

Performance Impact: --- → ?

I am also unable to reproduce this.

Please include a profile of this happening in Firefox. See https://profiler.firefox.com/, upload the profile and share the link here.

Flags: needinfo?(michael)

I'm now testing on the 2017 "Reference Laptop", Asus Core i3 over wifi.

My latency is very consistent (~40ms), with one singular spike of 70ms over the test.

Michael, in addition to the profile requested in Comment 4 (please use the "Network" settings from the pop-up), are there any other possible contributing factors?

Are you using any Web Extensions?

Thanks for the pointer to Firefox Profiler. I've just gotten back from a trip and got around to trying to repro this again. Unfortunately, it repro'd in Firefox and then immediately stopped when I restarted to do the repro in a private window with no extensions, etc. I will keep an eye out for it over the next week and capture a profile when I notice it, without trying to make it clean.

I had reproduced this in a private window, with no extensions, and only the Google Search and packetlosstest.com pages open.

There could be other factors, like other programs running either on my local system or elsewhere on my network, but I've done my best to eliminate them. I tested with a large upload, with a game running, with heavy CPU usage, and with a video call running, and while I saw interference it was not the same pattern. Previously, when I was seeing the issue, I tested from other systems on the same network, e.g. with my laptop in the same room, with both systems on wifi connected to the sole access point, and I did not see the issue on other systems.

Okay, I got it to repro somewhat - rebooted, started Firefox, running in my normal profile not a private window. Only saw one period of high latency but the shape of it is right. I've attached a screenshot of the packetlosstest run and the CSV of the run. I realized I forgot to include the settings in the screenshot, so they are based on the Rocket League preset, NJ server, changed to run for 20 seconds. The target frequency of the pings is 65/second, though it didn't quite get through them all as you can see in the screenshot.

Here's the profile. https://share.firefox.dev/3nsru60

I'll try to capture a better one, too.

Flags: needinfo?(michael)

Looking at the profile, it doesn't appear to have much of use. I'll try with capturing all threads.

Okay, here's a profile where the issue is better demonstrated. Two windows open, with GMail + packetlosstest.com in one and Google Search in the other. I cranked up all the capture settings, hopefully it's got something useful. This is in my normal profile, not a private session, so it does have extensions loaded, though I don't think any of them would munge WebRTC. https://share.firefox.dev/3JM1lGM

Thank you for the profiles Michael.
While I go through these, can I ask to try disabling the pref geo.enabled via about:config?
This ended up being the root cause in a similar issue - Bug 1810421.

Oh wow, the settings for that look like they correlate very well with my issue - the timeout is 6000 which I assume is 6000ms, and the period of the problem is roughly 6s.

I disabled the setting, and it didn't immediately help. However, after restarting Firefox, the problem was gone. I confirmed at https://bestvpn.org/html5demos/geo/ that geo was not supported. I then turned the setting back on and confirmed that geo was now supported again. Then the problem was immediately present again.

I also tried setting geo.provider.ms-windows-location to false, which did not help. I turned on Location in Windows Settings, restarted Firefox, and now geo works and is not causing latency issues. Seems odd that changing geo.provider.ms-windows-location doesn't change things.

Definitely a duplicate, great catch! Old bug, too, since https://bugzilla.mozilla.org/show_bug.cgi?id=1502532 seems to be the same thing.

I'll use the workaround of enabling Location in Windows 10 for now, though I'd generally prefer to have that off so that I can have more fine-grained control over that data. AFAIK there's no way to get Windows to limit access to Location data except for apps from the Windows Store. For desktop apps it's just on or off.

Thank you for verifying that Michael, much appreciated!
I'm sure we can get this fixed and thank you for your patience.

Duping this to bug 1810421, mainly because the primary investigation was done there and that is where we are ensuring this gets fixed.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1810421
Resolution: --- → DUPLICATE

To the reporter: we believe you can workaround in a more privacy preserving manner by setting the preference 'geo.provider.network.scan' to false. You may have to create this preference in about:config. That way you can continue to disable Windows Location Services.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: