This is a disclaimer: Using the notes below is dangerous for both your sanity and peace of mind. If you still want to read them beware of the fact that they may be "not even wrong". Everything I write in there is just a mnemonic device to give me a chance to fix things I badly broke because I'm bloody stupid and think I can tinker with stuff that is way above my head and go away with it. It reminds me of Gandalf's warning: "Perilous to all of us are the devices of an art deeper than we ourselves possess." Moreover, a lot of it I blatantly stole on the net from other obviously cleverer persons than me -- not very hard. Forgive me. My bad. Please consider it and go away. You have been warned!
BIC NTP Setup
3 servers, ntp[123], in an active-symmetric setup, ie, they will peer between them and multicast to local clients who can then chose one of them to sync their clock.
Server: ~malin/bin/crush /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst peer ntp1.bic.mni.mcgill.ca peer ntp2.bic.mni.mcgill.ca peer ntp3.bic.mni.mcgill.ca restrict −4 default kod notrap nomodify nopeer noquery restrict −6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 restrict 132.206.178.0 mask 255.255.255.0 nomodify notrap nopeer broadcast 224.0.1.1 (:sourceend:)
Client:
- sync to a single server
server ntp1.bic.mni.mcgill.ca server ntp2.bic.mni.mcgill.ca server ntp3.bic.mni.mcgill.ca (:sourceend:)
There are 2 main tools to probe the ntp state of a host: ntpdc and ntpq. Typical interactive commands for ntpdc are ‘peers’, ‘sysstat’, ‘sysinfo’, ‘iostats’, ‘authinfo’, and ‘peers’, ‘association’ and ‘rv’ for ntpq.
The fate codes for these tools are:
>>>>>>>>>>>>>>>> Fate codes for ntpq <<<<<<<<<<<<<<<<
<sp> discarded due to high stratum and/or failed sanity checks
“x” designated falsticker by the intersection algorithm
“.” culled from the end of the candidate list
“-“ discarded by the clustering algorithm
“+” included in the final selection set
“#” selected for synchronization but distance exceeds maximum
“*” selected for synchronization
“o” selected for synchronization, PPS signal in use
>>>>>>>>>>>>>>>> Fate codes for ntpdc <<<<<<<<<<<<<<<<
“+” symmetric active
“-“ symmetric passive
“=“ remote server is being polled in client mode
“^” server is broadcasting to this address
“~” remote peer is sending broadcasts
“*” the peer the server is currently synchonizing to
A typical situation on a stratum 3 server at the BIC. With ntpdc:
ntpdc> peers
remote local st poll reach delay offset disp
=======================================================================
*time2.srv.ualbe 132.206.178.242 1 128 377 0.04929 0.000534 0.13655
^ntp.mcast.net 132.206.178.242 16 64 0 0.00000 0.000000 4.00000
=email.applejell 132.206.178.242 2 128 377 0.01051 0.003083 0.05286
=zeus.yocum.org 132.206.178.242 2 128 377 0.00145 -0.000843 0.07091
+matsya.bic.mni. 132.206.178.242 3 128 377 0.00024 0.008388 0.06206
+varaha.bic.mni. 132.206.178.242 16 512 0 0.00000 0.000000 3.99217
+narasimha.bic.m 132.206.178.242 3 128 376 0.00018 -0.000251 0.07690
=ox.eicat.ca 132.206.178.242 2 128 377 0.00862 0.006950 0.07143
With ntpq:
root@varaha:~# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*time2.srv.ualbe .GPS. 1 u 109 128 377 49.299 0.534 0.615
+zeus.yocum.org 204.152.184.72 2 u 98 128 377 1.464 -1.906 0.552
-ox.eicat.ca 139.78.135.14 2 u 93 128 377 8.627 6.950 1.092
+email.applejell 64.90.182.55 2 u 92 128 377 10.528 3.083 1.661
narasimha.bic.m 208.69.56.110 3 u 28 128 376 0.308 -0.235 0.401
-matsya.bic.mni. 72.38.129.202 3 u 83 128 376 0.150 9.471 0.877
varaha.bic.mni. .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp.mcast.net .MCST. 16 u - 64 0 0.000 0.000 0.001