Basic NTP Client Test on Windows: w32tm

When implementing NTP servers, it’s always an interesting part to check whether the server is “up and running” and reachable from the clients. While I’ve done many basic NTP checks out of Linux, I lacked a small docu to do this with Windows. It turned out that there’s no need for third-party software because Windows already includes a tool to test NTP connections: w32tm.

This article is one of many blogposts within this NTP series. Please have a look!

So there is this tool called W32Time with many options to not just test NTP servers, but to configure Windows’ time service and so on. In our simple test case, we just want to query a server with these two options:

This displays a chart showing the offset of your local computer’s time (displayed as a | ) to the time delivered through NTP (shown as a * ). Missing replies are marked with a failure:

When the offset is really low, only the asterisk is seen:

Interestingly, when looking at the packets with Wireshark, you can see that the NTP version number is set to 1, while normally clients/servers are using version 4: (Packet 523 did not get an answer for whatever reason and was marked by w32tm accordingly.)

One more tool tip though: With w32tm /query /status you can verify which time source your computer is synced to. In my case, this was a local CMOS clock rather than an NTP server. That’s why the offset (in the first chart above) was about 1 second rather than smaller ones in the range of ms.

Please note that I’m neither testing the classical NTP authentication nor NTS at this point. It’s only about the reachability of the NTP server.

Soli Deo Gloria.

Photo by Brad Neathery on Unsplash.

 

2 thoughts on “Basic NTP Client Test on Windows: w32tm

  1. Just a short comment: the features, behavior and overall performance of w32tm / the Windows 32 time subsystem is heavily depending on the Windows version you look at. Newer versions are generally considered better/more accurate in my experience.

  2. And in addition to what Heiko said, the default configuration created for w32time used to depend on whether the Windows machine was originally configured as standalone machine, or as a member of an AD domain, which resulted in completely different behavior.

    Haven’t checked whether this is still true for the latest w32time versions shipped with Win11 and latest win10, though.

Leave a Reply

Your email address will not be published. Required fields are marked *