NTP Issues Today

Tue Nov 20 21:21:18 UTC 2012

On Nov 20, 2012, at 4:00 PM, Darius Jahandarie <djahandarie at gmail.com> wrote:

> Choosing the first four servers is usually pretty straightforward:
> *.CC.pool.ntp.org
> 
> But beyond that, I'm honestly rather curious what server selections
> are a good idea. A first thought would be an adjacent country, but
> maybe there is a benefit to picking things outside of the pool.ntp.org
> selection entirely?
> 
> I see that Jared used *.fedora.pool.ntp.org -- I wonder if there was a
> specific reason for that or if my questions are even worth thinking
> about at all :-).

I'm by no means a time geek, but …. i have some ideas about what you want and can tell you why I picked the settings I did…

1) The 129.250 ones are my employer run clocks.  It is a good idea to know how accurate they are.

2) The pool ones, some were default (e.g.: fedora) from my OS distro on the machine I took the example from.  You will see freebsd, centOS and others based on your settings.  You may even see time.apple.com if you are MacOS.

3) CC ntp pool were selected to provide additional clock diversity.

4) You want low jitter to your clocks.  This will allow you to have an accurate timing source.  This means don't congest that path.  If you want something very reliable, don't run it on a server with the other "misc" functions you need (e.g.: DNS, etc).  If it's important, dedicate some hardware to it.  if it is of passing importance, use a fair number of peers.

I was playing with the OWAMP software.  Having consistent clocks is important for that, (even if they are all off by a few ms). It can be fun to play with and measure things… http://www.internet2.edu/performance/owamp/index.html

5) Monitor your NTP setup periodically.  You may see clocks be rejected or outliers.  Depending on how close your clocks are, you may see a fair number be unusable.  Take this output:

nat:~$ ntpq -n -p -c ass
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*129.250.35.250  164.244.221.197  2 u  507  512  377   18.883    0.196  18.311
+129.250.35.251  209.51.161.238   2 u  366  512  377   41.349    0.429   2.184
-206.57.44.17    204.123.2.5      2 u   91  512  377   35.884   -5.982   7.099
-4.53.160.75     209.81.9.7       2 u    5  512  377   24.250    1.522   1.353
+64.73.32.135    164.67.62.194    2 u  296  512  377   26.405   -0.956  11.244
+50.116.38.157   64.250.177.145   2 u  897 1024  377   42.978    0.685   1.211
-208.87.221.228  10.0.22.51       2 u  390  512  377   83.858   -2.717   0.814
-206.212.242.132 128.252.19.1     2 u  262  512  377   22.278   -1.640   1.150
+38.229.71.1     204.123.2.72     2 u   95  512  377   20.688    0.113   1.878

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 39973  961a   yes   yes  none  sys.peer    sys_peer  1
  2 39974  941a   yes   yes  none candidate    sys_peer  1
  3 39975  9324   yes   yes  none   outlyer   reachable  2
  4 39976  932a   yes   yes  none   outlyer    sys_peer  2
  5 39977  941a   yes   yes  none candidate    sys_peer  1
  6 39978  941a   yes   yes  none candidate    sys_peer  1
  7 39979  9314   yes   yes  none   outlyer   reachable  1
  8 39980  931a   yes   yes  none   outlyer    sys_peer  1
  9 39981  941a   yes   yes  none candidate    sys_peer  1

Only 5/9 clocks are 'candidate' for usage, or the actual reference clock.  The jitter on the reference clock is equal to the delay (!).  This is on a business class internet link/tier, but from one of the 'usual suspects' that offers residential services as well.  I haven't been able to find them operating any customer accessible clocks, but they may exist.

My config, or one resembling it will give you a fair amount of diversity of clocks.  Syncing to one can easily result in being lied to and resetting the clock as everyone observed that went back to 2000.

- Jared