[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NTP Issues Today
On Nov 20, 2012, at 4:00 PM, Darius Jahandarie <djahandarie at gmail.com> wrote:
> Choosing the first four servers is usually pretty straightforward:
> 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
*188.8.131.52 184.108.40.206 2 u 507 512 377 18.883 0.196 18.311
+220.127.116.11 18.104.22.168 2 u 366 512 377 41.349 0.429 2.184
-22.214.171.124 126.96.36.199 2 u 91 512 377 35.884 -5.982 7.099
-188.8.131.52 184.108.40.206 2 u 5 512 377 24.250 1.522 1.353
+220.127.116.11 18.104.22.168 2 u 296 512 377 26.405 -0.956 11.244
+22.214.171.124 126.96.36.199 2 u 897 1024 377 42.978 0.685 1.211
-188.8.131.52 10.0.22.51 2 u 390 512 377 83.858 -2.717 0.814
-184.108.40.206 220.127.116.11 2 u 262 512 377 22.278 -1.640 1.150
+18.104.22.168 22.214.171.124 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.