Time difference between NTP servers

RyBoneCoder

8/4/24, 9:01 PM

I have a unique offline LAN. It contains two servers that get time from the same source. They do not reach out to the internet for their time source. They receive time from an application layer. I trust their time. I have a client that should sync to their time when I plug it into the network. All three of these devices run a Windows 10 LSTC. I jumped down the rabbit hole of learning how to wake the NTP services up inside of the OS. I went through a serious troubleshoot to understand the minimum configuration settings to where it started to work. I have been working with a test environment That consists of three devices. For my test environment I manually set the clocks on the two devices acting as the servers. So, there was natural drift on those two devices over a couple of weeks and that is where my question is going here.

On the servers the group policies are set to not configured.

Registry

W32Time/TimeProviders/NTP Server/enabled = 1

W32Time/Parameters/Type = NTP

W32Time/config/announceFlags = 5(hex)

After troubleshooting this is the minimum configuration required in order for me to be able to sync to one of these servers. I had a few other things set from reading stuff on the internet but I discovered this is all that is needed.

On the client side of things

Under group policy,

NTP client is enabled.

Configure NTP client is also enabled and is where I am specifying the IP address to sync with.

I'm able to give the client server1 IPAddress,0x8 under configure NTP client and it syncs.

I can then change it to Server2 IPAddress and it also syncs.

All of the above now leads me to my question. When I configured it to have both IP addresses [Server1 IP address,0x8 Server2 IPAddress,0x8] The client would no longer sync and W32tm /query /status showed CMOS clock. W32tm /query /peers showed it had 2 peers. However, when I did a W32tm /resync I would get a reply that said "The clock could not sync because there is no time data available". When I jumped down that rabbit hole I found everything under the sun except my specific problem. I tried all of the 32 commands like stopping the time and unregistering re-registering starting time and you name it. Nothing would work. When I turned one of the servers off after a couple of minutes it would start sinking with the one that was remaining. My specific problem didn't like when I gave it to IP addresses. By this time my test environment servers had drifted by about 4 to 5 minutes. I spent an entire week on this and had an idea of setting the one server to be much closer in time to the other one. Now my servers were about 10 seconds apart and everything magically started to work.

Sorry for the novel but I wanted to give the detail of my situation. Everything worked perfectly the last hour of my day today. Was the time drift difference between the servers really my problem? When I think about it multiple servers are going to be really close in a real environment. When I gave my client two IP addresses and it reached out to sink and those two servers did not agree in time did it force my client to decide that it couldn't rely on those sources and would automatically just switch to its own CMOS clock?

Thank you in advance for any wisdom given as I'm brand new to this topic.

108

1 + 0

local-area-network

ntp

Score:3

Server

HBruijn

8/5/24, 2:15 PM

It is NOT recommended to use only two NTP servers.

"A man with a watch knows what time it is. A man with two watches is never sure".

If more than one NTP server is required, three is the minimum required for quorum but in practice four NTP servers is the recommended number for redundancy and to protect against one incorrect time source, or "falseticker". See https://support.ntp.org/Support/SelectingOffsiteNTPServers#Upstream_Time_Server_Quantity

If you list just one, there can be no question which will be considered to be "right" or "wrong". But if that one goes down, you are toast.

With two, it is impossible to tell which one is better, because you don't have any other references to compare them with.
This is actually the worst possible configuration -- you'd be better off using just one upstream time server and letting the clocks run free if that upstream were to die or become unreachable.

With three servers, you have the minimum number of time sources needed to allow ntpd to dectect if one time source is a "falseticker". However ntpd will then be in the position of choosing from the two remaining sources.This configuration provides no redundancy.

With at least four upstream servers, one (or more) can be a "falseticker", or just unreachable, and ntpd will have a sufficient number of sources to choose from.

+ 2

RyBoneCoder

8/6/24, 2:05 AM

This answer is so amazing. It makes everything I have been doing the past 2 weeks makes so much sense. This is a difficult topic to learn. My architecture is what it is and cannot be changed. Your answer makes me understand my problem. I now need to understand the possible time drift possibilities in my actual environment. It may be a better decision to just give it one Time source say server one. If it goes down my client will trust itself until it comes back. But if I give it two time sources the man with two watches no longer understands what time it is. Thank you so much!

RyBoneCoder

8/6/24, 2:07 AM

It totally explains the result that I was getting and why when I turned one of them off it immediately started to sync. I wish the error that it was giving me was more detailed instead of just saying there's no time did it available. That seems to be a generic error that people get in about a thousand different situations. Thank you for taking the time

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Time difference between NTP servers

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.