Is it viable to use w32tm.exe's option stripchart to judge the time variance of two hosts (within a very small margin of error)? Note that w32tm.exe's stripchart function is separate than the algorithm used by the Windows Time service itself.

If not, what are some alternate methods?



2 Answers 2


The answer to your first question is "Yes, w32tm.exe (Windows Time) is able to measure the time variance of two network hosts within a very small margin of error (relative term.)"

The answer to your second question is "Yes, there are better ways to measure time variance between two hosts. Microsoft says so right here. They point you to NIST, which lists a whole bunch of other pieces of software (and hardware) that is probably better than w32tm.exe. I'm sure many of them are, since Microsoft clearly does not support w32tm.exe as an ultra high precision tool."

Windows Time (and w32tm.exe) are RFC 1305 (NTPv3) compliant, which includes compensating for network latency. Source and Source. Compensating for network latency is one of the very basic features of the network time protocol. (See Marzullo's algorithm, which is what NTPv3 uses.)

What frustrates me about your question is that high precision is so important to you, but you don't give any hints as to what exact precision you need. 1 second? 1 millisecond? 1 nanosecond? General purpose computers have a clock resolution that is bound to the frequency of clock interrupts received by the processor, which is usually controlled by a crystal oscillator that runs at 32.768 KHz (a power of two,) but that's sensitive to temperature, voltage, etc. The HAL on a typical Windows machine defaults to configuring the real-time clock to fire every 15.6 milliseconds, or about 64 times a second. However, you can still crank the RTC down to 1ms, and you can also subdivide that 15.6 millisecond time slice via software into even smaller slices for high-performance applications. Regardless, the NTP timestamp itself is a 64-bit unsigned fixed point number and so has a theoretical limit of about 232 picoseconds of precision, but the Windows Time implementation does not even approach that. Windows Time displays an NTP precision of -6 and doesn't support some of the latest and greatest NTP algorithms so in reality it could probably never reliably produce a precision tighter than one hardware clock tick, or plus or minus 16 milliseconds.

General purpose operating systems are not extraordinarily great clocks, especially if the time keeping algorithms are implemented in user mode where the executing threads get preempted constantly. Highly precise clocks are expensive.


The picture above is the frequency of clock interrupts on the system. Note that even clock interrupts (IRQL 28 on 32-bit Windows and IRQL 13 on 64-bit Windows) can be preempted by higher interrupts, such as inter-processor interrupts, and can cause accurate time accounting to be deferred, if even by a nanosecond.

So back to NTP.

w32tm /stripchart /computer: is a perfectly valid way to test the time delta between one Windows machine and another. It does account for network latency, which is implied by it being NTPv3 compliant as we discussed above. But don't take my word for it. You can see the transaction for yourself in a Wireshark trace (client packet sent by w32tm.exe to a Windows NTP server):

Wireshark NTP

Microsoft does not guarantee sub-second accuracies using Windows Time, because they do not need to support that in order for any of their products to work. However, that does not mean that w32tm.exe is not still capable of sub-second accuracy.

If you truly need more accurate time than this, you might eek out an extra millisecond or 10 of precision with another implementation of NTP that uses slightly different algorithms. But if you really need more accurate time, I personally wouldn't suggest NTP at all. I'd wire a cesium clock straight up to your machine and not use a preemptive operating system.

Edit 5/2/2017: The above information is out of date and does not necessarily apply to Windows Server 2016 and beyond. Microsoft has made some serious improvements to the accuracy of Windows Time in later operating systems.

  • Thanks Ryan. Thanks for posting the article, which I think is focused on how the Windows Time service is not accurate versus that of the w32tm.exe stripchart function itself. I am trying to figure out how viable it is to run stripchart on two separate PCs targeting an onsite NTP server. It is because I am using an application that outputs time stamps from now() (local machine time), and I need to compare the log entries of the output on both machines for drift. Maybe ntp has another similar tool to measure drift.
    – brandeded
    Commented Mar 18, 2013 at 21:00
  • Does the stripchart function if w32tm.exe handle packet latency properly?
    – brandeded
    Commented Mar 19, 2013 at 12:53
  • Where are you seeing a clear statement that says that the w32tm.exe tool's function stripchart accounts for latency? I see that the Windows Time service: "[passes information] to the clock discipline algorithm, which uses the information gathered to correct the local clock of the computer, while compensating for errors due to network latency and computer clock inaccuracy." I just ran stripchart and monitored API calls with rohitab's API Monitor, and it doesn't look like any latency measurements are taking place; but I don't know.
    – brandeded
    Commented Mar 19, 2013 at 14:01
  • 1
    I'm editing my question so as to avoid extended discussions in comments.
    – Ryan Ries
    Commented Mar 19, 2013 at 15:15
  • Thanks Ryan! You've answered my question cross referencing the RFC and the time data within the packets (which I will use to see if I see offset between that and the output of w32tm.exe's stripchart) [I will post back when I finish the test with these results]. Thanks for adding in additional info on the technicalities of off set and the poor time keeping capabilities of chips that aren't dedicated to time keeping. I'm not measuring atom collisions here, so we're mostly concerned with millisecond drift (possibly micro-second later). Simply, local CPU utilization causes the most drift for us.
    – brandeded
    Commented Mar 19, 2013 at 16:06

I can not locate whether w32tm.exe's stripchart accounts (or how it accounts) for latency and jitter. Instead, I located a thread on the ntp mailing list that directed the user(s) to three additional solutions that do measure latency and jitter:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .