Discussion about official Mozilla Firefox builds
Both of those results look abnormally unstable. Try testing with only a single tab on a fresh profile and see if things improve.
If you have no background processes stealing CPU/GPU time and you cannot figure out what's wrong, you may want to file a bug report.
Silk enabled on 120Hz should have an almost perfectly stable graph and smooth animation if it's functioning as expected (results from Win7 SP1 x64, i5-3570K, GTX770):
Silk disabled (unsmooth, with multiple stutters per second):
Google Chromium 43.0 r317532 (smooth, but with higher inter-frame jitter and than Silk):
On my main, dirty profile-
On a new profile-
If I put Nightly on fullscreen mode, the non-silk pattern is slightly more regular but far from smooth.
My computer setup-
i7-4771k, Nvidia GTX760 driver v347.52
Main monitor (where Nightly is placed): 1920*1080 connected via HDMI. Dynamic range is set to Full(0-255) in Nvidia control panel.
Second monitor: 1440*900 connected via DVI. I tried testing on this monitor, as well as with this monitor disabled, the results are nearly identical.
Win8.1 64bit. Background programs that may affect the pattern includes MacType, F.lux, and MSI afterburner.
Turning off nearly all non-essential background processes doesn't help a bit.
Blue line (render time) improves greatly if I set Windows to high performance mode (control panel -> power option). CPU is running at full speed 3.85GHz instead of 0.8GHz while running the test.
If I set both CPU and GPU to max performance mode, red/green line has moderate improvement but it is definitely not as regular as those posted by Virtual_ManPL and Cyberbeing.
My results on Win8.1 with this computer are identical to my Win7 results, so it doesn't seem to be OS specific. It doesn't seem to be refresh rate specific either, since my results at 60hz, 72hz, 85hz, 96hz, 120hz were also all nearly identical. I thought I should test that, since both Fanolian's & ViperAFK's poor results were on Win8.1, while Virtual_ManPL's and my own previous results were on Win7. Notably my Windows 8.1 install is pretty bare-bones though (drivers only, no background software, no antivirus/security software except Defender), since I literally only dual-boot into 8.1 maybe once every 6 months for software testing purposes.
As an experiment, try setting bcdedit /set useplatformclock true in an administrative command prompt, reboot, and see if it helps.
If it doesn't help, you can revert that setting back to defaults with bcdedit /deletevalue useplatformclock
FWIW, my previous results were also with High Performance mode set in Power Options, since that is what I use normally on this system. If I switch back to Balanced, the blue line has an appearance similar to a square wave as the CPU switches between various clocks, yet the green line remains nearly perfectly flat and consistent the entire time. So it doesn't seem like Balanced mode alone should break Silk VSync, yet High Performance mode (Minimum Processor State 100%) could potentially help if you are seeing spikes in the render time (blue line) directly correlate to stutters on screen. My tests have also been with e10s enabled, since it seems to have a minor positive effect on Silk stablility.
It may also be worthwhile to try running LatencyMon while running these Silk browser tests, to see if you have a DPC latency problem which could be causing issues with performance. If you do, try updating any drivers with high latency spikes and also try updating your motherboard BIOS.
Setting useplatformclock makes no different to the test.
But I find that I can get a smoother graph the first 2 minutes after rebooting. It reverts to irregular spikes afterwards. This is the best looking graph I can get without silk.
I don't know what I should be looking at in LatencyMon but I don't think that's the issue. http://i.imgur.com/9TkvQXz.png
p.s. I switched the ACPI HPET setting in BIOS too (enabled by default) but the result is the same.
^ file a bug?
I think my issue lies on my system rather than Firefox. Enabling Silk does reduce the variance of the red/green line greatly.
I find another bug that needs confirmation. STR:
1. New profile. Disable Nightly's hardware accleration. Restart Nightly.
2. run http://www.vsynctester.com/
Memory usage rapidly climbs to 3GB and drops to few hundreds for a few times. Eventually memory usage stays at 3GB+ and Nightly stops responding.
FWIW, the i7-4771k should have a constant rate TSC, which has a higher resolution than the HPET and should be stable even when your CPU is in a low power state, so I would expect Windows to be using it.
The silk implementation on Windows uses DWMFlush(), and the DWM is always enabled on Windows 8 and up I believe (except in fullscreen exclusive mode games), so it's very odd that it's generating such a variable rate. Perhaps the problem is at another level, like Firefox's nsITimer implementation, but I wouldn't expect that to fall back to a worse timer than the TSC either.
By the way, have you tried it without your second monitor connected? Maybe the two monitors have a different refresh rate, and that's messing with it.
HPET is always the highest resolution timer on the system, while TSC is lower resolution but also much lower latency and performance overhead. So while Invariant TSC and derivatives should prevent most issues, there can be sometimes be other factors as well which can affect Windows default TSC+HPET hybrid timer stability in relationship to the HPET exclusively. My i5-3570K has a constant rate TSC as well, but I remember back when I first built this PC back in 2012, the performance timer measurements were unreliable with random skew from reboot to reboot. It wasn't until a year or so later that a BIOS update seemed to resolve it. Whenever you run into potential timer reliability issues, testing other timer configurations is just basic troubleshooting. Unfortunately, this doesn't seem to be issue in Fanolian's case.
So that image is without Silk within those first 2 minutes of boot, and then the green/red line degrades? For Silk disabled, those graphs look pretty close to my own, aside from those couple massive spikes. Tight and consistent spikes on the red/green line for the most part, with a few irregularities.
Usually within a couple minutes after boot to desktop is when CPU power management starts kicking in. Does the red/green graph still degrade after 2 minutes even with High Performance power options set? If it does, I guess you could try disabling some of the deep sleep C-states like C3/C6/C7 in the BIOS to see if it makes any difference, but you really shouldn't need to do that in normal circumstances.
Ah, you're right. It seems the HPET is guaranteed to run at at least 10 MHz. Invariant or nonstop TSC frequency might be CPU dependent - I couldn't find any documented frequency, at least.
These are the result after disabling all C states in UEFI/BIOS :
non-Silk, CPU/GPU at high performance: http://i.imgur.com/cazrOqt.png
non-Silk, CPU/GPU at balance mode: http://i.imgur.com/z2MLTdA.png
Silk, CPU/GPU at balance mode: http://i.imgur.com/NAQwnFG.png
Silk, only CPU at high performance: http://i.imgur.com/GN3dzQ9.png
Silk, CPU/GPU at high performance: http://i.imgur.com/SAZxpxo.png
(In the last 2 images, the spike occurs when I press the capture key)
So, what do these results imply? Is there defects on my hardware or something?
What is C states and why does it make such a difference in my case? What are the side effects if I disable C states?
I followed your suggestions before disabling C states. Nothing makes a difference including unplugging second monitor, disabling on-board VGA, and connecting a monitor to on-board VGA.
Interesting. The only thing I can think of is that the TSC doesn't work right in the C-states, and this causes either Windows or something in Firefox to fall back to a worse timer. If you apply the 'bcdedit /set useplatformclock true' thing again (and reboot), leaving C-states disabled but forcing Windows to use the HPET, does the problem reappear? Though I would expect the HPET to be accurate as well, even if it has more overhead.
FYI - I reported it here Bug 1136781 - Memory leak with Silk enabled and HW Acc disabled
Who is online
Users browsing this forum: Bing [Bot] and 4 guests