dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1921
share rss forum feed


Cartel
Premium
join:2006-09-13
Chilliwack, BC
kudos:2
Reviews:
·TekSavvy DSL
·Shaw
·TELUS

[Info] HPET and DPC Latency....do you go there?

Click for full size
Click for full size
Anyone use HPET and bcdedit /set useplatformclock true ?
I have found with HPET disabled in the bios and bcdedit /deletevalue useplatformclock I have low latency and more "quickness" overall.

Whats your findings?

I'm using DPC Latency Checker and WinTimeTester
»www.thesycon.de/deu/latency_check.shtml
»forum.notebookreview.com/asus-ga···t7364805


eddiebbb

@bethere.co.uk
I found the opposite .
HPET enabled Absolute max = 474
HPET disabled = 683


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
reply to Cartel
The HPET will not necessarily guarantee higher accuracy/lower latency. It varies greatly across motherboard models and vendors; some HPETs are known to behave horribly wrong (latency all over the place) while classic ACPI timers or even things like classic TSC perform better on those platforms. Likewise, some folsk experience the exact opposite. The only timer that you should try to consistently avoid is the legacy i8254.

In other OSes, such as FreeBSD, there is a ranking/priority scheme given to each of the timer types, since a system often will offer multiple types of timecounters. Here's a below example:

$ sysctl kern.timecounter
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: TSC(-1000) ACPI-fast(900) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 62134
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.ACPI-fast.counter: 10911534
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.TSC.mask: 4294967295
kern.timecounter.tc.TSC.counter: 2444826332
kern.timecounter.tc.TSC.frequency: 2833590337
kern.timecounter.tc.TSC.quality: -1000
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 1
 

The line to pay attention to is kern.timecounter.choice. Each timecounter available is listed, and the number in parenthesis indicates the priority calculated by FreeBSD (higher is better). You can see that the ACPI timers (either called "ACPI-fast" or "ACPI-slow", it sometimes varies -- don't let the name mislead you!) are preferred over classic TSC. However on some other systems, a timecounter called "TSC-low" is ranked with higher priority than ACPI. My above system does not have an HPET (it's a server-class board), but generally speaking HPET timers on FreeBSD are ranked slightly below ACPI. Google "FreeBSD HPET" sometime and look at the results -- you'll see the feedback varying ("HPET is slow!" followed by "HPET is sometimes 2x faster").

On the Windows side of things, consider advice like this coming from someone who in the same post says "HTEP" twice (I have a hard time believing someone who typos HPET twice actually understands what timecounters do/how they affect a system at a low level).

TL;DR -- sure, if HPET on your motherboard is more reliable/works better for you, use it. If you aren't sure if your system has one, don't want to take the risk of encountering a buggy/crappy timer, or in general don't want to bother, then do nothing -- there's a reason Windows defaults to not using HPET (I've alluded to why in my above paragraph).

--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.