1718426 - Firefox requests small timer resolution

Status: UNCONFIRMED

(Core :: Networking, enhancement, P3)

Description

[bruno.uy]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Run firefox with a pinned gmail tab.

Actual results:

Run

powercfg /energy
to get
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 18348
Requesting Process Path \Device\HarddiskVolume6\Program Files\Mozilla Firefox\firefox.exe

Expected results:

Firefox should not request accelerated timers, specially for a background tab.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Netmonitor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Andrei Purice]

Hey Bruno,
Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Comment 3

[bruno.uy]

Hi Andrei,

Sorry it took me a week to reply. I could reproduce it with a freshly installed nightly release in Troubleshoot Mode:

Warnings
Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000
Requesting Process ID 16836
Requesting Process Path \Device\HarddiskVolume6\Program Files\Firefox Nightly\firefox.exe

Information
Platform Timer Resolution:Platform Timer Resolution
The default platform timer resolution is 15.6ms (15625000ns) and should be used whenever the system is idle. If the timer resolution is increased, processor power management technologies may not be effective. The timer resolution may be increased due to multimedia playback or graphical animations.
Current Timer Resolution (100ns units) 156250
Platform Timer Resolution:Timer Request Stack
The stack of modules responsible for the lowest platform timer setting in this process.
Requested Period 10000
Requesting Process ID 16836
Requesting Process Path \Device\HarddiskVolume6\Program Files\Firefox Nightly\firefox.exe
Calling Module Stack \Device\HarddiskVolume6\Windows\System32\ntdll.dll
\Device\HarddiskVolume6\Windows\System32\kernel32.dll
\Device\HarddiskVolume6\Program Files\Firefox Nightly\xul.dll
\Device\HarddiskVolume6\Program Files\Firefox Nightly\nss3.dll
\Device\HarddiskVolume6\Windows\System32\ucrtbase.dll
\Device\HarddiskVolume6\Windows\System32\kernel32.dll
\Device\HarddiskVolume6\Windows\System32\ntdll.dll

Comment 4

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 5

[(inactive) Nihanth Subramanya [:nhnt11]]

Interesting.... this doesn't seem to be a networking bug for sure, but I'm not sure where to move this bug to because it's unclear what code is requesting this timer resolution.

This feels like a general performance bug to me that needs further investigation to be triaged. Patricia, is this something you can help find an owner for?

Comment 6

[Patricia Lawless]

Moving this to Core::Performance so we triage it and find a better component for it.

Comment 7

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

This would be due to a call to win32's timeBeginPeriod, and we have a few of them: https://searchfox.org/mozilla-central/search?q=symbol:timeBeginPeriod
Assuming "Requested Period 10000" is in units of 100ns, that's a timeBeginPeriod(1).

I've added printfs at each location, and running Firefox with a pinned gmail tab, I only saw one ping, the one in libwebrtc's GetSystemReferencePoint(), which is only used for a very short time to gauge the GetSystemTimeAsFileTime precision.
If that's the one, I think it's fine.

Now, the first time I ran it, to setup the gmail tab, I actually also saw the one in EventTokenBucket::FineGrainTimers(), which looks like a rate-limiting class in Networking. This may be more worrying?
Forwarding to Core:Networking for further analysis.

(It could also be good to conduct an audit of all timeBeginPeriod()s, especially since it can impact other processes; More info at https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ .)

Comment 8

[Kershaw Chang [:kershaw]]

Dragana, could you take a look? Thanks.
It seems timeBeginPeriod is also used in neqo.

Comment 9

[Dragana Damjanovic [:dragana]]

We use higher timer resolution for neqo to be more accurate when we are sending packets. We only use it if it is necessary, i.e. if a callback should happen in a very short time period. This should not happen all the time, just occasionally.
Is this happening all the time? We may need to tweak the algorithm.

To confirm that this is neqo that is causing this, can you check that timers are not changed if you set network.http.http3.enabled to false (go to about:config and search for this string).

Thank you.

Comment 10

[Dragana Damjanovic [:dragana]]

Changing severity to NA because this is expected behavior, we may investigate to improve it.