Score:0

Windows NTP client not syncing with Linux server

cn flag

I'm trying to synchronize the time of three computer on a local network. Although having the smallest drift/error possible with the world/internet would be grate, it is not my concert. My main concern is to have the best possible synchronization between the three computer.

To achieve this, I have set up one of the two Ubuntu machines (192.168.1.50) to act as an ntp server. I have done this by edit the ubuntu ntp server config file in /etc/ntp.conf and add:

server 127.127.1.0 iburst
fudge 127.127.1.0 stratum 10

Then, I have checked that the other Ubuntu computer (192.168.1.71) is syncronized with it. First I have added server controlstation prefer iburst to the end of the /etc/ntp.conf and restarted the time service with sudo service ntp restart. After that, I can check that this two computers are properly time-synched by running ntpdate -q 192.168.1.50:

server 192.168.1.50, stratum 2, offset 0.001271, delay 0.02599
 8 Mar 11:06:36 ntpdate[17648]: adjust time server 192.168.1.50 offset 0.001271 sec

This seems to work properly, and 0.001271 offset is acceptable for my purpose. Next is to do the same with windows (192.168.1.201). First I check that the computers are in deed not synchronized:

w32tm /stripchart /computer:192.168.1.50
12:10:01, d:+00.0010124s o:-00.4908814s  [                          *|                           ]
12:10:03, d:+00.0005757s o:-00.4907188s  [                          *|                           ]

Which makes sense as the windows client is so far synchronized to time.windows.com:

w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0386977s
Root Dispersion: 8.2445365s
ReferenceId: 0x33917B1D (source IP:  51.145.123.29)
Last Successful Sync Time: 3/8/2022 12:13:23 PM
Source: time.windows.com,9
Poll Interval: 10 (1024s)

I changed the time server with w32tm /config /update /manualpeerlist:192.168.1.50,0x8 /syncfromflags:MANUAL and forced a resync w32tm /resync:

Sending resync command to local computer
The command completed successfully.

Then, checked again the time difference between the ubuntu ntp server and this windows machine:

w32tm /stripchart /computer:192.168.1.50
Tracking 192.168.1.50 [192.168.1.50:123].
The current time is 3/8/2022 12:22:01 PM.
12:22:01, d:+00.0005075s o:-00.4568042s  [                          *|                           ]
12:22:03, d:+00.0010415s o:-00.4566323s  [                          *|                           ]
12:22:05, d:+00.0009737s o:-00.4569219s  [                          *|                           ]

Which shows that the windows ntp client is clearly not synchronized with the ubuntu ntp server. However, if I check the status:

w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0314761s
Root Dispersion: 8.2468633s
ReferenceId: 0xC0A80132 (source IP:  192.168.1.50)
Last Successful Sync Time: 3/8/2022 12:20:37 PM
Source: 192.168.1.50,8
Poll Interval: 10 (1024s)

It clearly sas that the source is the right one (192.168.1.50) and that it was synchronized just before the query.

Score:1
tl flag

Are these Windows Machines Joined to an Active Directory Domain?

if so Default Group policy configuration will be overriding any manual NTP config you try.

You could configure in Group Policy the custom NTP config for client machines but it is totally unadvisable to use custom NTP for AD client workstations as this could quite easily lead to drift between your clients and your domain controllers and if it gets beyond the magic 5 minute mark Kerberos blows up and your logins will start failing

The best practice is for your PDC role Domain controller to do NTP to the internet, then all your clients pick up via the PDC and other Domain Controllers

The configuration status output doesn't actually show any errors or reasons to think that its not syncing with the NTP server - what makes you think it is not syncing?

Its important to note that NTP won't constantly resync, it polls at a specific window that gradually slows down over time to maintain load, its currently saying that it will poll/sync its time every 1024 seconds which is just over 16 mins intervals.

It is also important to note that CPU clocks and CMOS clocks/crystals on board motherboards will all have very slight variances in frequency which all contributes to why you get time drift in the first place, 456ms of variance while does not seem that brilliant is still well within the realms of very acceptable unless you are dealing with very time sensitive (like needing less than 1s accuracy) or realtime kernel based - which you likely wouldn't be using windows for in the first place ;)

Score:0
gg flag

Also note that most NTP implementations try their outmost to not step the clock of the machine they're running on. Instead they try to speed up the clock to eventually catch up with the time source. This is to avoid the clock jumping forward or backwards in time, as some applications doesn't like this very much. And less than 0,5 seconds is definitely below the threshold for stepping the clock, so I'd wager the machine will catch up with the NTP server within a day or so. Also keep in mind that NTP (and not PTP either for that matter) doesn't offer absolute synchronization of two machines, it's always within a tolerance. I can't remember the achievable tolerances off the to of my head, but it's around milliseconds with NTP and micro/nanoseconds with PTP.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.