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.
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:
|
1 |
w32tm /stripchart /computer:HOSTNAME-OR-IP |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
C:\Users\jweber2>w32tm /stripchart /computer:ntp3.weberlab.de ntp3.weberlab.de wird verfolgt [[2001:470:1f0b:16b0::dcfb:123]:123]. Es ist 29.09.2023 09:31:07. 09:31:07, d:+00.1196315s o:+01.2824897s [ | * ] 09:31:09, d:+00.0666032s o:+01.2738181s [ | * ] 09:31:11, d:+00.1376563s o:+01.1849168s [ | * ] 09:31:13, d:+00.1089684s o:+01.2882442s [ | * ] 09:31:16, d:+00.0238122s o:+01.2431296s [ | * ] 09:31:18, d:+00.2107968s o:+01.2974940s [ | * ] 09:31:20, d:+00.0223062s o:+01.2419022s [ | * ] 09:31:22, d:+00.1731343s o:+01.2643331s [ | * ] 09:31:24, d:+00.0819059s o:+01.2757827s [ | * ] 09:31:26, d:+00.0359837s o:+01.2362617s [ | * ] 09:31:28, d:+00.1817614s o:+01.2444196s [ | * ] 09:31:30, Fehler: 0x800705B4 09:31:34, d:+00.0135745s o:+01.2475575s [ | * ] 09:31:36, d:+00.0184675s o:+01.2438881s [ | * ] ^C |
When the offset is really low, only the asterisk is seen:
|
1 2 3 4 5 6 7 8 |
C:\Users\jweber2>w32tm /stripchart /computer:ntp3.weberlab.de ntp3.weberlab.de wird verfolgt [[2001:470:1f0b:16b0::dcfb:123]:123]. Es ist 29.09.2023 11:26:47. 11:26:47, d:+00.1652050s o:+00.0843570s [ * ] 11:26:49, d:+00.1185437s o:+00.0199126s [ * ] 11:26:52, d:+00.1057113s o:+00.0478628s [ * ] 11:26:54, d:+00.0935680s o:+00.0391876s [ * ] 11:26:56, d:+00.1525955s o:+00.0712276s [ * ] |
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.
|
1 2 3 4 5 6 7 8 9 10 |
C:\Users\jweber2>w32tm /query /status Sprungindikator: 3(nicht synchronisiert) Stratum: 0 (nicht angegeben) Präzision: -23 (119.209ns pro Tick) Stammverzögerung: 0.0000000s Stammabweichung: 0.0000000s Referenz-ID: 0x00000000 (nicht angegeben) Letzte erfolgr. Synchronisierungszeit: nicht angegeben Quelle: Local CMOS Clock Abrufintervall: 10 (1024s) |
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.
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.
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.