[ntp:hackers] Windows 8 has a microsecond-precision system clock

Dave Hart hart at ntp.org
Fri Mar 2 12:37:41 UTC 2012


On Fri, Mar 2, 2012 at 06:55, Terje Mathisen <terje at tmsw.no> wrote:
>> This is a new API, GetSystemTimePreciseAsFileTime().  Existing
>> applications and C runtimes built for earlier Windows will continue to
>> see a lower-precision clock -- applications have to opt-in to using
>> the likely much slower new API.  The existing
>> GetSystemTimeAsFileTime() API is particularly fast as it does not
>> involve any calculation or any kernel mode transition overhead -- it
>> simply reads 64 bits from shared memory mapped into every process
>> which contains the time as of the last system clock tick (between 64
>> and 2000 Hz).  The new API likely involves a kernel transition to read
>> the performance counter (which is always provided by the HAL and
>> requires the kernel transition), plus a scaling operation to convert
>> the counter value to the wall-clock timeline using the low-precision
>> 64-bit shared memory clock and a new stored counter value taken at the
>> time of the last system clock tick.
>
>
> I.e. the default interpolated time algorithm on all platforms that have one,
> excepting the kernel transition:

My understanding is the presumed Win8 approach matches the approach
taken by Linux, that is, maintaining a low-precision system clock for
some uses (in Linux, kernel-internal use only I understand) as well as
interpolating a high-precision hybrid clock between the ticks of the
low-precision clock using a counter.  In contrast, I believe FreeBSD
builds its system clock solely using the counter -- that is, there
simply is no low-precision system clock.

> If Microsoft wants to do this properly, then they really do need two things:

I had a different implementation request, that the new precise variant
takes into account the observed rate of the performance counter,
rather than simply assume it runs at exactly the nominal rate.  ntpd's
Windows interpolation code currently fine-tunes the rate of the
performance counter over the first hour or so based on measurement
against the disciplined system clock, resulting in slightly less
jitter that immediately after startup.  The nominal and observed rates
are logged occasionally when interpolation is used:

 1 Mar 10:44:47 ntpd[1192]: Performance counter frequency 2.143 MHz
 1 Mar 11:02:48 ntpd[1192]: ctr delta -7416 exceeds limit 2092
 1 Mar 11:02:48 ntpd[1192]: ctr 2.135718 MHz -3460.35 PPM using
2.143134 MHz  +0.00 PPM
 1 Mar 11:02:48 ntpd[1192]: 1 ctr samples exceed +/- 976 PPM range gate
 1 Mar 11:20:48 ntpd[1192]: ctr 2.143028 MHz -49.46 PPM using 2.143099
MHz -16.33 PPM
 1 Mar 11:38:48 ntpd[1192]: ctr 2.142993 MHz -65.79 PPM using 2.143052
MHz -38.26 PPM
 1 Mar 11:56:48 ntpd[1192]: ctr 2.143007 MHz -59.26 PPM using 2.143010
MHz -57.86 PPM

I'm not sure what triggered the anomalous first calibration period,
but it seems to have been handled appropriately.  The calibration
continues but the logging becomes much less frequent after this.

> a) Determine if a non-priv operation can read the high-res counter (i.e. is
> this a single-core machine, or a new enough cpu that RDTSC (or similar) can
> get user-mode access to a system-wide stable counter.
>
> b) If a, then use RDTSC inside the GetSystemTimePreciseAsFileTime() code,
> avoiding any user/kernel round trip.

I agree it would be nice if they optimize it when feasible.  I think
the pieces are in place for a program which cares to be able to make
that optimization at runtime even if Microsoft doesn't.  My impression
is on newer x86/x64 processors that declare their invariant TSC via a
processor capability bit, QueryPerformanceCounter is indeed
implemented using RDTSC.  It's relatively easy to detect if QPC is
built on RDTSC, and ports\winnt\ntpd\nt_clockstuff.c in ntpd does this
already.  When it is, one just needs to occasionally sample the offset
to be able to substitute fast RDTSC instructions for slow QPC calls.
Calling GetSystemTimePreciseAsFileTime, GetSystemTimeAsFileTime, and
RDTSC in short succession, the program can then emulate the former
using the fast latter two.

>> 3.  Better understanding of what changes the precision of the system
>> clock on Vista, Win7, and Windows Server 2008 from the boot-time value
>> of 15.6 msec between ticks to 0.5 or 1.0 msec ticks, which change can
>> occur after ntpd starts and has decided to use its interpolation hack,
>> which then falls over into a mass of noise on the order of 15 msec.
>
> Don't ask for too much here, it has taken them 15-20 years to wrest some
> clock control back from the HAL!

I can dream... My reading, for what it's worth, is that once NT killed
of Win9x, it inherited the creepy product manager types dominating the
development decisions, lobbying for all resources to be focused on
their goals for the next version and against any core improvements not
clearly demanded by problems in the field.  But I may be biased,
having left NT development in 1998 disgusted by a couple of levels of
CYA managers unconcerned with fixing identified bugs if there was any
conceivable risk they might be held accountable for fix-induced
regressions.

Given the pattern of Windows releases, I fully expect Win8 to be
wildly hyped by Microsoft up until the industry repeats the Vista
experience and pans it as junk no one with sense would deploy widely,
convincing itself the next release will be the bee's knees.  And it
will be, as by the time the successor comes out Win8 will have worked
through the API disruptions and evolved critical mass of support for
new APIs and driver models, so like Win7 the follow-on version will
have relatively smooth sailing in terms of app and device
compatibility in the real world.  If the Vista experience is any
guide, I also expect Microsoft to dramatically cut back on maintenance
effort invested in Win8 service packs once the successor starts
selling, leaving relatively glaring bugs in Win8 to be fixed only in
the next version.  Vista and Win8 get the arrows in the back, Win7 and
"Win9" reap the windfall and get much larger and timelier deployment.

Here's hoping a Win8 service pack or successor release grow
SO_TIMESTAMP support at least.  The IP stack isn't a DDK sample I can
misappropriate like serial.sys...

Cheers,
Dave Hart


More information about the hackers mailing list