revisiting hpet bcdedit tweaks: what are your timer bench results and settings?

[zoulztealer]

View attachment 366257View attachment 366258View attachment 366256
0.5 to the left, 0.507 to the right. Vanilla test in the centre. Windowed/fullscreen seems to have zero difference. Apparently these tools only do harm to the performance (or don't impact it at all, idk). Gaming tests didn't reveal any difference. CP2077 shows exactly the same FPS in all scenarios. 1% and 0.1% lows stay where they were.

intresting. the tweaks and tools have different effects for each system and each system may require a different combo of tweaks. i did get a lot of noticeable improvements from all of this. there was an article from guru3d where they tested process lasso with a ryzen 1700 and it improved a lot but i cant find that one anymore. process lasso is also known to fix issues with intel p+e cores cpus for gaming by properly assigning and utilizing cores. it should also work better than the default windows, intel or amd scheduler, power plans, etc thats why process lasso comes with its own hi performance power plan, too, where core parking is disabled by default, which usually has a very good effect for gaming.

but the overall situation with the timers and hpet is definitely a shady thing for sure. if a system is already well optimized there likely wont be much difference or only hard to tell and also improvements can be due to multiple factors and show in various ways or dimensions. "higher numbers" / mere better values alone should not always be mistaken as the only important point of measure / data since you can have high fps / max fps etc but stuttering, jittering or input lag etc etc

0.5 and 0.507 show some weird stats though: the 0.507 has significantly more synthetic calls of ca. 1mil 10k but the 0.5 has more game calls of ca. +40k and 0.5 definitely improved over vanilla by ca +100k game calls. id go with the setting that gives you higher calls in games for example so either 0.5 or 0.507 and they could also improve your input latency or sth else - max fps / highest number is not the only thing to go for. since vanilla has the highest synthetic calls in could be thought of as the theoretically fastest setting but its game calls prove different and 0.5 and 0.507 indicate to be better suited for gaming.

vanilla was run in windowed mode which is different to the two other modes but you get a lot of fps more there. ive seen similar effects here too and windowed mode gives me way higher gpu load. it should also be asked why game calls are so low but fps are way higher compared to the other two: you have less timer calls but more fps in windowed mode than in fullscreen and that is sth to be investigated.

it seems for your pc as was the case before, too, hpet is always on in bios but should likely be forced disallowed in the os for best performance.

youre likely at setting 1 now (default / undefined) which is probably also the most optimal setting overall, 2 or 3 would probably also work for you and could potentially improve or worsen sth and trying out different combos as well was also what the author of timerbench said to try out.

1. TSC + TSC without desync: bcdedit /deletevalue useplatformclock - bcdedit /deletevalue useplatformtick - make sure HPET is enabled in BIOS

2. TSC + RTC: bcdedit /deletevalue useplatformclock - bcdedit /set useplatformtick Yes

3. HPET + RTC: bcdedit /set useplatformclock Yes - bcdedit /set useplatformtick Yes - make sure HPET is enabled in BIOS

combos are quoted from here:

https://sites.google.com/view/melodystweaks/misconceptions-about-timers-hpet-tsc-pmt

the basic tweaks are also a good read from the same author but these settings can be "dangerous" and you really have to know what youre doing altough the author himself states otherwise:

Basic Tweaks that are good to know and don't interfere with power saving features and other stuff.

Melody's Ultra Tweaks Pack - Basic Tweaks

Basic Tweaks that are good to know and don't interfere with power saving features and other stuff. For people who don't want to perform deep tweaking. Updated Jul 15 2020. Windows Firewall Warning. Updated Aug 1 2022. DalDramClockChangeLatencyNs seems to cause massive flickers on some AMD GPUs,

sites.google.com

the changes / results / effects can be very subtle and could depend on other factors or requirements / prerequisites, too, on how they play out in the end. note that some games or apps run better with hpet off but generally all kinds of apps heavily depend on hpet and the fact that its forced on now in newer mainboard means a lot and mainly intel cpus / chipsets seem to be affected by the hpet issue. newer games and multitasking generally run better with hpet on but it all depends on the specific case. and again high or max fps are not the one and only thing to look after but you want frametimes low and flat and the game to be noticeably smooth, fluid and the os to be snappy.

i received a lot of noticeable decrease of input latency from decreasing mouse and keyboard buffer from registry and this is certainly one of the best tweaks and absolutely safe:

note decimal 16 is the lowest possible value afaik for mouse and keyboard each:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\mouclass\Parameters" -Name "MouseDataQueueSize" -Type DWord -Value 0x00000010
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\kbdclass\Parameters" -Name "KeyboardDataQueueSize" -Type DWord -Value 0x00000010

i would generally recommend to have hpet "forced on" (like i have which is combo 4 here as i listed them) and if it works out well in total with the rest of the pc / config etc - otherwise leaving everything at default, disabling it or trying other combos seem to be the next best steps and worth the try, too, again depending on the specific case. my pc for example works incredibly well with all in on hpet could be it works better without could be not. i have tried before but i felt like its better this way probably.

4. HPET + RTC: bcdedit /set useplatformclock Yes - bcdedit /set useplatformtick Yes - make sure HPET is enabled in BIOS + disabledynamictick yes + tscsyncpolicy enhanced

the 4. combo will probably also be what hw and sw manufacturers are going to aim for and prefer in the future which is all focused on and done by hpet for cross compatibility and scalability, "one timer to bind all other timers".

heres another bench and config that seems similar to mine and frametimes which translate to fluidity / smoothness of ingame fps are way better with hpet on than with off - although one could be mistaken by the scale of the graph - and also note that even 6-fold more itsc games calls and 31-fold more synthetic calls do not translate into more ingame fps and this tells me ryzen probably run better with hpet on and theyre not affected by the hpet bug as much as intel on first glance.

note that frametime values can be relatively identical but the appearance from the graphs and the ingame effect will be different.

the reason / idea behind my bcdedit settings were i wanted to have all timers solely come directly from the hardware like mainboard / cpu as much as possible and avoid / prevent any synthetic timers from the os as much as possible. i also ran the same settings with hpet disabled in bios for quite some time before i switched over to on and everything seemed fine with off too and which would be this combo:

disable hpet on hw level yet force os to use alternative hw clock / timer (this combo would be the ideal solution for maximum performance theoretically):
3. PMT + RTC: bcdedit /set useplatformclock Yes - bcdedit /set useplatformtick Yes - make sure HPET is disabled in BIOS

 

[zoulztealer]

another thing i wanted to add is how you can rebuild - or maybe even possibly repair - performance counters or issues with timers etc and build an energy report as well that shows which timers and resolutions are used per process:

https://leansentry.zendesk.com/hc/en-us/articles/360038645792-How-to-Fix-performance-counter-issues

Manually rebuild performance counters - Windows Server

Describes how to manually rebuild performance counters.

learn.microsoft.com

How to create energy report on Windows 10

You can create a power efficiency report to understand and resolve energy-related problems with your Windows 10 device, and in this guide, we'll show you how.

www.windowscentral.com

cap frame x from a few minutes of 64 player bf2024 mp game vsync 60fps/60hz rtss cap 59.97 pre rendered frame 1 dlss 720p->1080p ultra / high quality / two monitor w. 100+ browser tabs open youtube video playback:

war thunder benchmark / offline, note fps are way more stable in single player scenarios:

quake champions menu fullscreen:

and borderless:

timerbench fullscreen:

and windowed:

 

[zoulztealer]

wanted to make a little demonstration what i mean of "absolute smoothness" with vsync on so i recorded one of the doom eternal cutscenes because they just run super smooth. and even the gameplay can be absolutely smooth on the screen and on recordings / streams etc capframex can still report values that look bad on the surface but dont have to be when you are using a fps cap & vsync.

i notice i get around 20-40ms app latency in fps type games from the capframex overlay ui. i dont know how this is related to input or total latency but it shouldnt be that bad for vsync on config. theres no stuttering during the cutscene and the frametime graph is absolute flat all the time. the scene has been run multiple times before to eliminate disk loading interference etc on benchmarking.

further noticed some games are able to run nvidia reflex on + boost with vsync on at the same time - while for others vsync needs to be off for nvidia reflex allow to work / setting become available in options menu. found that quite intresting becaue reflex should always work in each case. it was also important to set just the right ammount of fps cap.

doom eternal fullscreen test.mp4 288,1 MB 1080p60 / 59.98fps @60hz, dlss 720p->1080p, vsync on triple buffered, present from compute enabled

288.11 MB file on MEGA

mega.nz

basically a lot of games especially single player run super smooth like this and other well optimized mp games. i just did a fresh gpu driver clean install and adjusted the irq policy to "all close processors" because it says it can work with numa. everything seems to work well.

IrqPolicyAllCloseProcessors
Value: 1
The operating system should assign interrupts from the device to processors that are close to the device. On non-NUMA computers, the effect of this value is identical to that of IrqPolicyAllProcessorsInMachine.

 

[zoulztealer]

latest diablo 4 dlc performance analysis (courtesy of computerbase.de):

the 7900xtx performs way better with frametimes than the 4080 super. this is another indicator that amd hardware can generally be seen as superior to nvidia but has always lacked a certain ammount of software compatibility.

for smooth frametimes in the end it all comes down to how good the hw and sw have been optimized beforehand. every chip, every driver, every bios, os setting and game will yield different frametimes in the end - but there is a certain amount where the user can and needs to take a noticeable influence on the frametime performance with tweaking and optimizing - yet much more would have to be done and demanded from the manufacturer side which has been getting away all those years and decades with unresolved bugs and other issues while always demanding a full price to be paid for severely flawed products.

ive also noticed theres a very important optimal value / area of values where fps needs to be capped at in order to produce absolute smoothness in vsync, for example my fps should be capped around sth like 59.96-59.98 and it should never be set to 59 or 60 or other values since this will cause a build up of frames and stuttering in an interval. this was discussed in the blur buster low latency guide for vsync: https://blurbusters.com/howto-low-lag-vsync-on/ note: you should never comletely disable pre-rendered frames; ie set them to 0 because most of the games and apps simply wont work well without a pre-rendered frame; youll need at least 1 pre-rendered frame minimum for optimal performance and compatiblity.

Technical explanation: This avoids frame buffers from piling up to create input lag. In addition, stutters are avoided, thanks to RTSS microsecond-accurate frame rate capping precision. High speed video tests confirmed a reduced lag of approximately 1 to 2 less refresh cycles less input lag relative to VSYNC ON. Also, RealNC from Blur Busters Forums has a longer HOWTO on Guru3D Forums on this technique, including additional tips on how to edit your RTSS configuration file, and setting pre-rendered frames to 1 in NVInspector.

if you use triple buffering or other features i imagine you would probably need even more pre-rendered frames to be allowed but it all depends on your config and the app / game etc and for some systems even 0 pre-rendered frames / "ultra low latency" may also work perfectly or better than 1 or 2 pre-rendered frames.

contrary to the recommendation in the guide fon low latency vsync from blur busters ive realized it is better if you make the setting in nvcpl / amdcpl to let vsync be decided and handled by the app / game and not make the setting forced on by the driver and turn vsync inside the game off as is recommended in the guide: driver handels vsync, game renders unconstrained max fps and supposed lowest input latency. i could confirm this but the game is smoother if it can handle the vsync itself.

since every game has its own special kind of vsync implementation letting vsync be decided and handled by the game instead of the driver will be always a better choice in terms of performance and compatibility as well.

computerbase.de writes in their article:

Diablo 4: Vessel of Hatred im Benchmark-Test: Benchmarks (FHD, WQHD & UHD), Frametimes und VRAM

Diablo 4: Vessel of Hatred im Test: Benchmarks (FHD, WQHD & UHD), Frametimes und VRAM / Das Testsystem und die Benchmark-Szene

www.computerbase.de

Differences are apparent in frame pacing Diablo 4: Vessel of Hatred does not compile shaders in advance and you can feel it. After a new graphics card has been installed or a new driver has been installed, the game twitches hopelessly, especially in the first few seconds of play. At least, after a few minutes of playing time, all shaders are apparently compiled, at least you can no longer feel any sudden stuttering. However, when entering a new environment or executing a new ability, the game may stutter again the first time.

There are differences in frame pacing between an AMD and an Nvidia graphics card. The Radeon RX 7900 XTX shows very good frame times, but there are constant small frame time spikes that don't have to be like that, but are not noticeable with a sufficiently high frame rate.

The GeForce RTX 4080 Super, on the other hand, has more problems. Not only do the frame time spikes occur more frequently, they have also become larger and longer. Instead of around 1.5 ms variance between frames on the Radeon, the test scene on the GeForce shows a variation of around 3 ms. With a sufficiently high frame rate, this is not a problem, but if the FPS falls into the range of 60 FPS or less, the game feels a little smoother with a Radeon.

RTX 3080 Ti GPUs Are Mysteriously Dying On Diablo IV Beta

Lilith's reaping RTX 3080 Ti souls.

www.tomshardware.com

another frame test video of war thunder of how absolute vsync smoothness should look like; app latency was around 10-20ms:

war thunder fps test.mp4 104,4 MB

104.45 MB file on MEGA

mega.nz

 

[zoulztealer]

not only it seems that for intel more than amd hpet *can* be pretty much equal and ok in a lot of games - but also that there are issues with hpet in itself and probably also with synchronization of timers and conversion of different timers / timer settings between the os and the game / app because the game engine uses a specific timer that must first be transformed.

the fact that hpet on works great with amd should actually make them pretty good for gaming and even profits again with it off while for intel it would be recommended to have it always turn it off.

the charts come from this article:​

A Timely Discovery: Examining Our AMD 2nd Gen Ryzen Results

www.anandtech.com

- "Given that the difference between the two sets of data is related to the timer, one could postulate that the more granular the timer, the more the effect it can have: on both of our systems, the QPC timer is set for 3.61 MHz as a baseline, but the HPET frequencies are quite different. The AMD system has a HPET timer at 14.32 MHz (~4x), while the Intel system has a HPET timer at 24.00 MHz (~6.6x). It is clear that the higher granularity of the Intel timer is causing substantially more pipeline delays – moving from a tick-to-tick delay of 277 nanoseconds to 70 nanoseconds to 41.7 nanoseconds is crossing the boundary from being slower than a CPU-to-DRAM access to almost encroaching on a CPU-to-L3 cache access, which could be one of the reasons for the results we are seeing, along with the nature of how the HPET timer works.

There is also another aspect to gaming that does not appear with standard CPU tests: depending on how the engine is programmed, some game developers like to keep track of a lot of the functions in flight in order to either adjust features on the fly, or for internal metrics. For anyone that has worked extensively on a debug mode and had to churn through the output, it is basically this. If a title had shipped with a number of those internal metrics still running in the background, this is exactly the sort of issue that having HPET enabled could stumble upon - if there is a timing mismatch (based on the way HPET works) and delays are introduced due to these mismatches, it could easily slow down the system and reduce the frame rate."​

i argue that the hpet issues are mainly due to it being bugged and not properly implemented yet. it needs more work and attention and performance and compatibility should increase with the future by new hardware and software and bios updates etc as well, too. in the end it seems like it all depends on the engine for the greatest part. the higher the resolution the smaller the difference becomes in some cases and this can have several reasons where maybe one of it is that things become a more gpu bound scenario. this is also a performance tip for pcs with strong gpus but weak cpus (max out game gfx and res).

author of timer bench mentions hpet as best choice for gaming:

this channel does really good benchmarking with a lot of the settings and tweaks that have been mentioned in the thread and much more:

Alchemy Tweaks

At this channel, we focus on computers and Windows, with the primary goal of demystifying, clarifying, and exposing any misinformation out there. Here, you’ll find videos that are well-documented and seriously analyzed with strict methodology... Discover the rest by watching the videos. I'm...

www.youtube.com

 

[Apocalypsee]

I did one final trick that now I didn't hear or feel anymore audio dropout, that is disabling Intel VMD RST driver. Previously when I try to disable this in BIOS I'm unable to boot to Windows because it didn't recognize the partition that I need to reformat. Turns out it's very easy to 'bypass' this. Simply run this in cmd or powershell 'bcdedit /set safeboot minimal', then reboot into BIOS and disable RST and next boot you will be able to boot Windows, just run cmd/powershell again and run 'bcdedit /deletevalue safeboot' and next reboot you're back into regular Windows!

 

[zoulztealer]

theres been a nice to know update on mpo in a recent blog from the losless scaling app on steam:

• With the latest Windows 11 24H2 update, Microsoft changed how the Desktop Duplication API (DXGI) functions, making it heavily reliant on MPO (Multiplane Overlay) support. Without MPO, DXGI cannot reliably distinguish between updates from game window and the LS window when both are displayed on the same monitor. This prevents it from capturing only new frames, thereby breaking the existing framepacing algorithm.
  
  MPO support varies between systems, and there is no definitive way to determine why it is supported on some setups and not on others. You can use dxdiag to check if your system has MPO support. In some cases, you might be able to work around the issue. For instance, if you have two monitors connected, disconnecting one may force the remaining monitor to support MPO.
  
  As of the 24H2 update, DXGI is no longer a reliable capture method unless Microsoft changes its approach or Nvidia and AMD improve MPO support in their drivers.
  
  On the other hand, Microsoft has addressed a five-year-old bug in the Windows Graphics Capture (WGC) API, which previously prevented it from capturing only new frame updates. Starting with version 24H2, WGC now works as expected for the most part. Essentially, DXGI and WGC have switched roles in this update. WGC capture in LS has been updated with a new framepacing algorithm to replace DXGI on newer systems while maintaining the same behavior as before on older systems. DXGI continues to function normally up to version 23H2, but beyond that, it depends on MPO support.
  
  While WGC generally offers some advantages over DXGI, such as allowing LS to be recordable by most tools, it also has drawbacks without MPO support. Specifically, in games where a hardware cursor is displayed and VRR is enabled, WGC disables independent flip mode globally. This can lead to issues with LS and VRR functionality.
  
  Starting with Windows 11 24H2, MPO support becomes highly desirable. We can hope that future updates from Microsoft, Nvidia, and AMD will address these challenges. Notably, there have been reports that DXGI is functioning correctly again on the Windows 11 Dev branch.

Lossless Scaling - Resolution Scale, SGSR v1, and Windows 11 24H2 Compatibility - Steam News

Introduced a new "Resolution Scale" option for LSFG. This feature allows input frames to be processed at a reduced resolution while generating output at the original resolution. For example, when playing at 1440p, setting the scale to 50% enables LSFG to generate 1440p output from a 720p input...

store.steampowered.com