Gear GeeksGaming

Should you disable HPET for gaming, and does it reduce input lag?

No, not on a default Windows install, because on most PCs Windows is not using HPET for its high-resolution timestamps in the first place. The setting that can hurt is the opposite one: a forced useplatformclock flag that makes Windows use HPET. Delete that flag if it is there, and leave the BIOS alone.

LatencyUpdated 6 min read

Disabling HPET does not reduce input lag on a normal gaming PC, because Windows is not timing anything with HPET to begin with. Since Windows 7, Microsoft's own documentation says most PCs use the processor's time stamp counter (TSC) as the basis for the performance counter, and drop back to HPET only when the TSC is unsuitable. The tweak that actually costs you something runs the other way: forcing HPET on with bcdedit /set useplatformclock yes. If that flag is set, delete it. Otherwise, leave everything at default.

Why two answers circulate

HPET advice comes from two different eras, and both halves get repeated as one rule.

In Microsoft's "Acquiring high-resolution time stamps", the Windows Vista section says every computer that shipped with Vista used HPET or the ACPI PM timer as the basis for QueryPerformanceCounter (QPC), and that "such platform timers have higher access latency than the TSC". From Windows 7, "the majority" of computers use constant-rate TSCs instead, and the Windows 8 and 8.1 section says those versions "use TSCs as the basis for the performance counter". On systems where the TSC is not suitable for timekeeping, "Windows automatically selects a platform counter (either the HPET timer or the ACPI PM timer)".

So "HPET is slow" is true, and "disable HPET" sounds like the fix. But the only HPET change with a documented mechanism is removing a forced useplatformclock flag, which pushes a modern PC back onto the platform timer. Turning HPET off in the BIOS of a PC that was never using it for QPC removes nothing from your click-to-photon chain.

What the platform timer actually costs

QPC is what Microsoft tells native code to use for timestamps. The same document gives the cost of each source:

Cost of one QPC read by time base, from Microsoft's QPC documentation. Per-frame share is our arithmetic at 240 fps (4.17 ms per frame).
QPC time baseCost per callKernel transitionOne call as share of a 240 fps frame
TSC (default on most PCs)About 30 ns typical (3 GHz example)Not required0.0007%
HPET or PM timerFrequently 0.8 to 1.0 µs"A system call is required"0.019 to 0.024%

Per call, the platform timer is roughly 27 to 33 times more expensive, and Microsoft adds that a platform counter is "shared between multiple processors", which "limits scalability of QPC if it is called concurrently from multiple processors".

What the table cannot tell you is how many calls a given game makes per frame, because no game publishes that. The honest test is to measure your own latency before and after removing a forced flag, and to watch frame times and 1% lows rather than average fps.

Every HPET tweak, and what to do with it

"Disable HPET" names at least five different settings. They do different things:

HPET and timer tweaks, with Microsoft's own description of each. Checked 2 October 2026.
TweakWhat Microsoft says it doesVerdict
bcdedit /set useplatformclock yes"Forces the use of the platform clock as the system's performance counter." "Should only be used for debugging."Harmful. Delete it.
bcdedit /set useplatformclock noSame option, set to not force. Microsoft documents /deletevalue to return an option to default.Harmless, but delete the value instead.
bcdedit /set useplatformtick yes"Forces the clock to be backed by a platform source, no synthetic timers are allowed." Debugging only.Delete it.
bcdedit /set disabledynamictick yes"Enables and disables dynamic timer tick feature." Debugging only.No documented benefit. Delete it.
bcdedit /set tscsyncpolicyControls the TSC synchronization policy. "Should only be used for debugging."Delete it.
HPET off in the BIOSNot a Windows boot option. Removes one of the two fallback timers.No documented gain. Leave it on.

The BCDEdit /set reference opens with a caution that changing some boot options "could render your computer inoperable". Every timer option on that page carries the same note: debugging only. None is described as a performance setting.

How to check your PC in two minutes

  1. Confirm the TSC is invariant. Download Coreinfo from Sysinternals and run coreinfo -f. Find the line TSC-INVARIANT * TSC runs at constant rate. An asterisk means true. This is the check Microsoft's QPC document itself shows. The current release lists Windows 11 as its minimum client.
  2. Look for forced flags. In an administrator command prompt, run bcdedit /enum {current}. If useplatformclock, useplatformtick, disabledynamictick or tscsyncpolicy appear, someone set them.
  3. Delete them. Run bcdedit /deletevalue useplatformclock, and the same for any other listed option. Per the /deletevalue reference, you might need to suspend BitLocker and Secure Boot first, and the change applies after a restart.

Do not use the performance counter frequency as your test. Microsoft says some newer Windows versions always report 10 MHz, and warns: "don't assume that QueryPerformanceFrequency will return a value derived from the hardware frequency."

The verdict

  1. BIOS HPET: leave it on.
  2. Forced useplatformclock: delete it. This is the only HPET change with a documented cost behind it.
  3. Every other timer flag: delete it. Microsoft labels each one debugging only.
  4. Then spend the time on the settings that move milliseconds, in the settings checklist.

Where this stops applying

If Coreinfo shows a dash on TSC-INVARIANT, or Windows has decided your TSC cannot be synchronized across cores, Windows has already chosen a platform timer by itself, which Microsoft describes mainly for large server systems with multiple clock domains. Inside a virtual machine, Microsoft expects the hypervisor to clear the invariant TSC bit where live migration could change the TSC frequency, so a guest reading is not a reading of your hardware. And none of this applies to Arm-based Windows PCs, which have no TSC or HPET and use the Arm Generic Timer.

Frequently asked questions

Does disabling HPET reduce input lag?

Not on a default Windows install. Microsoft's documentation says Windows uses the processor's TSC as the basis for the performance counter on most systems since Windows 7, and falls back to HPET or the ACPI PM timer only when the TSC is not suitable. If HPET is not the timer in use, switching it off changes nothing in that path.

Should I turn HPET off in the BIOS?

There is no documented benefit. On a system with an invariant TSC, Windows does not use HPET for the performance counter anyway. On a system without one, Windows needs a platform timer, and HPET or the PM timer is what it falls back to. Microsoft also notes that Windows 7 and Windows 8 hardware certification requires HPET support in the platform.

What does bcdedit /set useplatformclock yes do?

Microsoft's BCDEdit reference says it "forces the use of the platform clock as the system's performance counter" and that the option "should only be used for debugging". On a TSC-capable PC it swaps a counter that is read in about 30 ns for one that costs 0.8 to 1.0 microseconds per call and needs a system call.

How do I undo useplatformclock?

From an administrator command prompt, run bcdedit /deletevalue useplatformclock and restart. Microsoft documents /deletevalue as the way to remove options that were added with /set, and a boot option change only takes effect after a restart.

Should I set disabledynamictick yes?

Microsoft describes it only as enabling and disabling the dynamic timer tick feature, and says the option "should only be used for debugging". It publishes no gaming or latency benefit for it. Leave it unset.

Sourcing. Timer behaviour, access costs and the Coreinfo check are from Microsoft's "Acquiring high-resolution time stamps" (updated 13 December 2025). Option wording is from Microsoft's BCDEdit /set and BCDEdit /deletevalue references and the Sysinternals Coreinfo page, all linked in the text. The tweak-by-tweak verdicts and the per-frame arithmetic are ours. Found an error? Send a correction.