Another look at HPET High Precision Event Timer

Be aware that Steam, Origin and UPlay set timer resolution to "1.0".

 

The best guide there is for HPET/Timers, Mouse Polling, Lag Input, Windows Services. it is just everything in one place, get this file and save it!

https://docs.google.com/document/d/1nrcQ2EU5512TpuspPF4u5PgZ43p7hoV1cYBMi2C3XSQ/edit?usp=sharing

Also video from the creator




Also to check if the hardware of the mouse is ok, go here with EDGE only, because chrome is limited to 60 Frames and won't pass to 1000Hz frames

https://www.vsynctester.com/testing/mouse.html


Also, use the program to check the issues with mice in windows. Check the polling and frequency which is the main source of bad timings, bios settings, Cpu Power Saving.

https://www.overclock.net/forum/375-mice/1590569-mousetester-software-reloaded.html\

More about Mouse USB Polling
https://www.overclock.net/forum/375-mice/1550666-usb-polling-precision.html

 

Some things in that video are just claimed without any evidence. So I asked him simple question but he answered me without answering the question.

 

Yep, alot of it is absolutely nonsense.

especially the part where the 10ms virtualized timer is the cause of the dpc latency... lol.
no, that was a kernel bug in a win32 query timer api.

 

Don't spread that kind of bullshit around. Thanks.
Even the first sentence with chrome is wrong.
Not even talking about his mentions about Roach's thread in the overclock.net forums and bullshit like enabling CSM or installing Windows in MBR Legacy mode for lower "latency".

I lol'd hard tho, thanks.

 

The thing with these guides is they take a really long time to compile, so I appreciate the creator taking the time to make those tweaks floating around available in one text file.
However, as with most of these guides, they include a lot of snake oil and placebo and it's really up to the reader to pick and choose the tweaks that they feel might be worth it.

 

Even by using these recommended values:

DISABLE HPET
bcdedit /set useplatformclock no

DISABLE SYNTHETIC TIMERS
bcdedit /set useplatformtick yes

ISLC still reports 0,4999ms and not the 0.5ms as shown in the video

 

Blow me, a 0.02% or less error.
Terrible.






ps this post is a joke

 

you should know that many people contributed to this guide and that's not just him. so many people with experiences had different fixes.

Also believe or don't believe, from what I saw he is right on many things. so if you don't have the problems/issues or the skills to notice them, then it's something else. not talking about Mbk.

*This guide will constantly be updated, so please come back and recheck it regularly.
I did not invent or discover any of these myself, this list is compiled from the internet and personally tested by me. I can’t take credit for the tweaks themselves but I can take credit for compiling everything and spending the time to debunk/test them.*

&AND please, if you can do better I am waiting for a guide or fix to solve all the issue me and others are having. if you have them why not sharing them?

What motherboard and do you have HPET Enabled on bios?

This is what you should use

useplatformclock No
useplatformtick Yes
disabledynamictick Yes

And if you still can't get 0.5 then you have bios timing issue or something else. Check for bios update or Bios update over the one you have.

Another thing Enabling MSI on the Geforce card on the Desktop makes the mouse better. That why on laptops and AMD cards are better because they have it Enabled it already. so if you don't enable on desktop you gonna have crappy mouse

 

@X7007

That was my question to that guy from YT video you posted: you claim that when timer resolution is not strict 0.5 it is bad, but why it is bad? have you experienced the difference between 0.5 and say 0.4999? And he replied to me ignoring the question.

Also I should note that "useplatformclock no" is of no use because Windows will not use any platform clock (not necessary HPET) even in absence of "useplatformclock no". And no app can turn that setting on the fly because OS kernel should be initialised with that setting, i.e. reboot is mandatory.

 

I agree.
A PCs accuracy reporting time in this manner is not that precise.
0.4999ms is easily within the bounds of error of 0.5ms.
Would he care as much if it was 0.5001ms I wonder, specially as this is likely to be a bigger error.

 

Well, from my experience I had an issue with weird things I can't explain. Because it happens quickly or to fix it you just restart the computer. and I'm talking about everyone here ,you are not gonna investigate an issue that you can't even understand, and u just want to fix it. because we don't have the tools and Windows also screw many things and also Bios and drivers.
Maybe the guys just don't know what issues there are, or he can't explain, but it would cause issue as the Timings must be syncronized with the CPUs or else you get performance weirdness and thread issues.

I did had many times different timings with the Intel 3770k with Asus P8Z77. I could get 0.5001 or 0.5002 or 0.4996 or 0.4998. It was the timings. but I don't remember exactly what controlled them. but with HPET on bios + windows, it was always 0.5000.

maybe it is correct, but who can tell us? I know Gigabyte released many Beta Bioses for different motherboards to people requesting HPET Toggle on bios, and they released it. my friend didn't have HPET on his bios and we found on site that they release beta BIOSes with HPET toggle.

Can find it here
The official bios he had was F6 and the latest beta is F7c. GA-Z97MX-Gaming 5 - F7c

https://forums.tweaktown.com/gigabyte/28441-gigabyte-beta-bios.html



And the whole reason to be happy when you have such guide is to know YOU ARE NOT ALONE. why people banging other people contribution without any reason.

Also if talking about MSI-X here, my Network card can do over 32 to max 1024
I have 2 ports so one is enabled the other disabled, I didn't bother to change the other one
It's 1950x
Do you think it's gonna help with something Mbk?

 

Z77 Pro3 and yes, hpet is on

I have the latest bios

 

@X7007

The problem with system timer resolution functions (from Windows API) - they do not operate with milliseconds, they use units "100 nanoseconds".
And system timer resolution is not related to timings directly, system timer resolution means interval between kernel ticks (clock interrupts). With each such tick OS kernel checks every timers (an OS object with interval, periodic flag and callback function) created by programs (or drivers) - are there timers with expired "alarm"? and for such expired timers their callback function is called.
For example, some app needs some periodic action - check or do something every 5 ms. It creates periodic timer (with Windows API function) with 5 ms interval, and registers special function as a timer callback. Now if system timer resolution is default 15.6 ms you understand that requested 5 ms for this timer will be maintained not always because 15.6 ms is significantly larger than 5 ms. But if system timer resolution is 2 ms (or less) then requested 5 ms for this timer will be achieved practically constantly.
So difference between 15.6 ms and say 1 ms in system timer resolution is crucial for (small) timers in apps. But difference between 0.5 ms and 0.4999 ms is not so obvious for me.

 

If multiple messages (MSI) per one device are used then you see all them in device manager in "Resources by type => IRQ" view. If you see one IRQ (negative) for device then only one message (MSI) is used for device. Limit allows you to limit the number of messages per device. But of course it has no effect if message is one.

PS All these multiple MSI per device are about server world. I saw only two devices - storage controllers and network controllers - in server OS with multiple MSI.

 

Nvme uses 2048 so that's the reason it can do so many Queues at the same time.

 

So you see 2048 (negative) IRQs for NVMe?

 

yes for example

 

You see one IRQ for MVMe controller with the limit 2048. Limit is 2048, but device uses one IRQ (-13).
So no matter what limit you set - device doesn`t need that value because only single MSI is used.

 

From obvious reason yes. but PCI-E doesn't have limit... that's the whole point. SolarFlare 8xxx and 9xxx can do over 2048 queue, but it doesn't show on windows. you could see maybe on their driver or software but it does work. if the limit is not visible on the PCI-E ports that don't mean they can't do more than 1.