2

I have a linux box, set up with two ntp servers to sync. This box in case, was extremely out of sync (61 seconds) before it was forced sync. The following outputs are 1 hour after this sync. When checking the ntpq,

ntpq> peers                                                                           
          remote           refid      st t when poll reach   delay   offset  jitter     
==============================================================================     
x192.168.[redacted]   .MDM.            1 u  113  256  377    0.513   13.120   1.843     
x192.168.[redacted]   .MDM.            1 u  115  128  377    2.689    0.618   1.230

Both are set to falsetickers!

ntpq> assoc                                                 

ind assID status  conf reach auth condition  last_event cnt 
=========================================================== 
  1 13191  91d4   yes   yes  none falsetick   reachable 13  
  2 13192  91d4   yes   yes  none falsetick   reachable 13

What has led the time choosing algorithm to set both as false, and how can I fix it?

UPDATE!

I have rerun the commands above and got new status:

ntpq> assoc                                                                     

ind assID status  conf reach auth condition  last_event cnt                     
===========================================================                     
  1 13191  91d4   yes   yes  none falsetick   reachable 13                      
  2 13192  96d4   yes   yes  none  sys.peer   reachable 13                      
ntpq> pe                                                                        
     remote           refid      st t when poll reach   delay   offset  jitter  
==============================================================================  
x192.168.[red]   .MDM.            1 u  241  256  377    0.513   13.120   1.396  
*192.168.[red]   .MDM.            1 u  114  256  377    2.671    0.567   0.710
MadHatter
  • 81,580
kurast
  • 123

2 Answers2

5

Your two upstream servers both claim to be stratum-1 servers - that is, the highest class of time source that is able to speak NTP, one to which an absolute time source (such as an atomic clock, or a GPS receiver) is directly attached - but their clocks are different from each other (that is, your offset from each server (how far away your clock is from its, when you receive its signal) is much more than the observed propagation delay (how long it takes to get a time signal from each server)).

Faced with two servers who both claim to be authoritative but are telling different times, ntpd is quite reasonably saying that it can't decide between them and it will regard them both as charlatans.

It now looks like, left to itself, ntpd has decided after an hour that it prefers one to the other, and agreed to sync to it. Good for it.

The basic problem here is that the upstreams are between them saying something which cannot possibly be true. If you only want a rough time, list only one of them in your ntp.conf, and you'll sync to that much more quickly. If you want an exact time, contact the admins of the servers, and ask them why their clocks differ, and where each of them is getting its time source.

Edit: if I were to guess, I'd say that both of them are wrong - my guess is they've both been configured to treat their internal clocks, or some similarly insufficiently-accurate time source, as stratum-0. They may also have been configured to take time from internet servers, but since they've been told that they have an absolutely-accurate clock attached, they're preferring that time, and advertising as stratum-1 in consequence.

MadHatter
  • 81,580
3

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

You need to add another server so that ntpd can break the tie between two clocks. Of all the possible numbers of server associations, two clocks is the worst setup. It does not matter if third server is stratum 2 or stratum 3, you just need to give ntpd a chance to discern who is the falseticker.

PS

You do not need to redact your RFC1918 addresses. In fact it makes it harder to answer when you redact them like this. It would be better if you switched which octets you redacted: xxx.xxx.1.1 and xxx.xxx.1.2. Atleast that way it is easy to refer to one or the other. But most importantly there is really no need to redact 1918 addresses.

dfc
  • 1,371