[nSLUG] Why is ntp so terrible?

Dop Ganger nslug at fop.ns.ca
Fri Mar 10 12:20:14 AST 2017


On Fri, 10 Mar 2017, D G Teed wrote:

> that isn't the nature of this inaccuracy.
> 
> ntpq -p on the main ntp server which I will call ntp.example.com:
> 
> # ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *time12.nrc.ca   132.246.11.233   2 u  178 1024  377   19.666    0.291   0.620
> +time1.chu.nrc.c 209.87.233.52    2 u  254 1024  377   46.781    3.205   8.099

Have you considered setting up a GPS to get a reliable stratum 1 time 
source?

> The ninth entry in the list has the time in the sample as 08:50:45
> 
> Here is ntpq -p run on the 9th system with 8:50:45:
> 
> # ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  ntp.example.com  .INIT.          16 u    - 1024    0    0.000    0.000   0.000

ntpd stuck in INIT usually means it can't connect to the configured 
upstream. Try watching tcpdump after restarting ntpd to see where packets 
are going?

> One thing I am looking into is IPV6.  This is enabled on the main ntp server
> and I notice the systems where IPv6 has been disabled seem to have consistent
> time.  The others may have attempted IPv6 connections and failed due
> to firewall on IPv6 being blocked for most services.  I have changed the firewall
> on the central ntp server to allow IPv6 connections with udp 123 - maybe this
> will improve the outcomes.

IPv6 can interfere with DNS operations, we usually disable it in our 
environment.

You might also want to look at openntpd - it's less featured than ntpd but 
works simply and well.

Cheers... Dop.


More information about the nSLUG mailing list