The HPET bug: What it is and what it isn't - Seite 2
URL: https://www.overclockers.at/number-crunching/the-hpet-bug-what-it-is-and-what-it-isnt_251222/page_2 - zur Vollversion wechseln!
mat schrieb am 23.10.2019 um 11:03
mat schrieb am 26.10.2019 um 03:02
- Detection of iTSC QPC mode with 10 MHz (since Windows 10 RS5)
- Fixed crashes when loading result files
- Implemented multi select for result file dialog to load more than one result at once
- You can start more than one measure process dialog now inside one TimerBench application
- Measure process now additionally takes a process id to target a specific application for measurements
- New icon! Let's go professional.
- Updated all libraries to their latest version: HWiNFO 6.12, PresentMon 1.5.2, EasyHook 2.7.7097
- All executable and DLL files are now signed with my SHA2 signature
- Compiled with Visual Studio 2017 (staticly linked MFC und VC)
Download: TimerBench 1.4 (172 MB, Self-extracting Exe, CRC32: 39a1a4c7)
Prerequisites: DirectX 11
LordGurciullo schrieb am 15.01.2020 um 07:24
You're clearly a genius.
I've optimized my system to the max but I wanted to try the HPET off thing.
Is it going to help? I have a 9900k at 5ghz 4133 ram and a 2080 super overclocked.
What are your thoughts?
LordGurciullo schrieb am 17.01.2020 um 09:17
I've tried every combination of everything and I haven't gotten any solid results in latencymon for reducing latency and no fps gains... Any ideas?
Marctraider schrieb am 24.02.2020 um 15:09
Hi. Great program but i think there is a bug with it.
I suspect the program also seems to count frametimes that happen when the 3D window is just activated and moving around the screen to place itself, causing wrong frametime output in the end result varying from 25 to 60+ms!
The whole time my frametimes are well below <1ms and steady 1000+fps.
So result are inaccurate anyway.
mat schrieb am 24.02.2020 um 16:36
You can check the frame times yourself by importing PresentMon.csv in the Results directory right after the test. You will find all the raw values there.
Important are the columns "MsBetweenPresents" and "Dropped". The final frame times values are calculated from all frame times that are not dropped PLUS the first 5% of the test are ignored due to loading anomalies in Unreal. Meaning your suspicion won't check out.
This is for example a GTX 1080 Ti in windowed FullHD (just the first 16 seconds of the test):
mat schrieb am 25.02.2020 um 22:02
- Added awesome graphs to visualize the results of the Game Test. Available data: Frametimes, GPU Load, GPU Frequency, GPU Memory Frequency, CPU Load and CPU Max Frequency (the fastest core)
- Added the 99th Percentile average for frametimes to the result dialog. This shows the value that's better than 99% of all frametimes captured during the Game Test.
- Changed warmup period of Game Test to 3 seconds (instead of 5% of the collected data). To show all ignored values that are not part of the final result, the warmup period is shown as a red line in the graphs.
- Improved detection of the primary graphics cards
- Improved detection of SLI/Crossfire configurations. To keep things simple, the Game Test's sensor data will only capture the first card.
- Latest HWiNFO version 6.23 integrated
- Implemented with C++17, compiled with Visual Studio 2019 (staticly linked MFC und VC)
Download: TimerBench 1.5 (173 MB, Self-extracting Exe, CRC32: 34EC2A27)
Prerequisites: DirectX 11
Marctraider schrieb am 01.03.2020 um 15:25
Awesome nice job! Btw I'm now consistently at 4/5ms frametimes!
But I like this graph idea, tried importing them csv into CapFrameX but only shows a few seconds each time.
Marctraider schrieb am 01.03.2020 um 16:07
tw. With this version I'm getting constant 'Could not read frametime data'.
[16:06:08] Demo window found!
[16:06:08] Injecting QPC hook DLL: C:\Users\Administrator\Desktop\Tools\TimerBench 1.5\QPCHook32.dll
[16:06:08] Starting PresentMon with session: TimerBench2128
[16:06:08] Starting PresentMon trace session
[16:06:41] Stopping PresentMon trace session
[16:06:42] PresentMon successfully stopped
[16:06:42] Parsing result file: C:\Users\Administrator\Desktop\Tools\TimerBench 1.5\Results\PresentMon.csv
[16:06:42] File not found or no access: C:\Users\Administrator\Desktop\Tools\TimerBench 1.5\Results\PresentMon.csv
Marctraider schrieb am 01.03.2020 um 16:10
Nvm. Works after a reboot. Suspect that CapframeX is conflicting with it as they both use PresentMon logger
mat schrieb am 01.03.2020 um 16:14
Yeah, if the output file is opened with a tool, it is locked for further access. Copy it first to another location if you want to do some further analysis.
Lowprofile18 schrieb am 30.03.2020 um 09:20
Ran 2 test on each in windowed and fullscreen. A bit confused on the results, which is better?
Also does adjusting dynamictick in bcdedit have an effect with these tests?
mat schrieb am 30.03.2020 um 11:03
Please upload the screenshot to this forum. I can't read a single number on my mobile.
Lowprofile18 schrieb am 30.03.2020 um 18:16
Sorry about that, here it is
mat schrieb am 30.03.2020 um 19:04
All results are pretty good. Enabling HPET does not hinder your performance at all, so if you want, you can leave it enabled.
If there would be a problem, it would look like this:
The Intel Core i9-10980XE takes a huge performance impact with HPET enabled
Check the frame times between the HPET and the TSC timer results, especially the 99th Percentile, which is a good measurement to see if your framerate was stable or had frequent stuttering (it means 99% of all frames you saw on your screen were better than x milliseconds):
HPET: 5.16-5.57 ms
TSC: 5.36-5.55 ms
HPET: 8.80 ms
TSC: 1.78 ms
That's a frametime about 5 times worse than without HPET enabled.
Dynamic Tick is something that can result in higher latencies because your system "ticks" only when it's needed, which can be slightly later than when it ticks at a fixed frequency (normally 64 times a second, sometimes even 1000 times a second). A tick is a wakeup for your OS to do certain things, like do some thread scheduling, increment some timers like your taskbar clock and so on.
You can disable it, but it might lead to higher power consumption, because your system has to do more work during idle.
On Windows 8 this feature was still buggy and led to a skewed taskbar clock. So it made sense to disable it back then. Today there shouldn't be any visible or even measureable advantage of a fixed tick frequency.
© all rights reserved by overclockers.at 2000-2020