NTP daemon HowTo

I really have no idea why the NTPd documentation is so bad. It's long, incromprehensible and does not cover running a time server in depth. So here I note what's important. You should know the rest.

/etc/ntp.conf

There was a bug in Debian which renders old NTP servers unusable. I ran into that bug. This is important. Remove "nomodify" from the "restrict" lines as follows:
restrict 127.0.0.1
restrict ::1

Here is an example condensed ntp.conf file. Do not use Stratum 1 Servers without their permission! So don't blindly take this example for your! YOU HAVE BEEN WARNED!

driftfile /var/lib/ntp/ntp.drift
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server ptbtime1.ptb.de.
server ptbtime2.ptb.de.
server ntp2.fau.de.
server ntps1-0.cs.tu-berlin.de.
server rustime01.rus.uni-stuttgart.de.

server 127.127.1.0
fudge 127.127.1.0 stratum 13

restrict 127.0.0.1
restrict ::1
This is an example for Germany. If you are somewhere else, pick some of your country's Stratum 1 servers. Please honor NotificationMessage if you pick a Stratum 1!

Notes for "server" settings if you poll Stratum 1 servers

If you do not comply to this section, you are rude, act abusively and may harm the net.

  • If you use ntp to only serve yourself or a handful other machines, do not use Stratum 1 Servers. Instead use pool.ntp.org.
  • burst, iburst: Never use this option. Do not even think about it.
  • minpoll: the default 6 is ok. But never go below 6. If you want to be nice, increase to 7 to 9.
  • maxpoll: the default 10 is ok. But never go below 10. If your hardware needs a lower value, buy a better hardware or abstain from synchronizing with Stratum 1 servers.
What is Stratum? Perhaps see en.wikipedia.org/wiki/Network_Time_Protocol

  • Stratum 0 are direct clock reference sources, like the atomic clocks or GPS satellites. Usually you cannot even buy this, you have to build and operate this yourself.
  • Stratum 1 are those servers, which have access to a Stratum 0, so they do not rely on another very stable time clock, like atomic clocks or GPS reference hardware. Note that serving the time through an GPS receiver can be considered Stratum 2, too, as the GPS receiver can be considered to be a Stratum 1 and not 0. This depends on your taste.
  • Stratum 2 servers are those servers which ask some other Stratum 1 servers to give a reliable clock source.
  • Stratum 3 are servers, which serve the time and have Stratum 2 servers in their query list.
  • And so on.
  • Stratum 16 is considered unsynchronized.
If you offer the time to pool.ntp.org, this is, list your server in pool.ntp.org, then it is expected that you are either Stratum 1 or Stratum 2.

If you are Stratum 3, that is, you ask other pool.ntp.servers for your time to distribute it back to pool.ntp.org, then you are probably only helpful if there are too few other servers in your region and you cannot rely on only the few reachable Stratum 1 servers because your country's Internet connection is not stable enough. (If you want to do something good to your country then, get a GPS based reference clock and become a Stratum "1.5" for your region.)

How to check correctness

You should see a Star (*) in the output of following after running ntpd for a few minutes:
ntpq -p
Example output:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ptbtime1.ptb.de .PTB.            1 u   48   64   17   21.853    2.901   7.274
+ptbtime2.ptb.de .PTB.            1 u   48   64   17   20.578   -9.205   9.210
 ntp2.rrze.uni-e .PPS.            1 u   39   64   17    7.743   -0.705   6.228
 ntps1-0.cs.tu-b .PPS.            1 u   47   64   17   20.169   -1.299   6.400
 rustime01.rus.u .PPS.            1 u   44   64   17    9.451   -4.095   6.041
 LOCAL(0)        .LOCL.          13 l   52   64   17    0.000    0.000   0.000
  • *: Your NTP is synchronized to this server. (o would be your preferred server, # an equally good backup source)
  • +: Your NTP uses this as secondary source.
  • -.x: (and blank) discarded for various reasons.
  • refid/st: Explains the clock source and stratum of the Server. PTB is atomic clock, PPS is either GPS or DCF77 receiver.
  • t: "u"nicast or "l"ocal. You hardly see something else here.
  • when/poll: when counts seconds up to poll, then the server is asked. Here 64 is the minimum.
  • reach: A bitmask, 0 for fail or polling in progress, 1 for successful answer. The LSB (&1) is the latest.
  • delay/offset/jitter: Are given in ms (Milliseconds)
Here an example even a few minutes later:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ptbtime1.ptb.de .PTB.            1 u   35  128  377   21.576   35.732  21.841
+ptbtime2.ptb.de .PTB.            1 u  117  128  377   20.730   39.152  20.063
+ntp2.rrze.uni-e .PPS.            1 u   26  128  375    7.613   33.050  26.082
+ntps1-0.cs.tu-b .PPS.            1 u   58  128  377   19.661   47.043  14.210
*rustime01.rus.u .PPS.            1 u   58  128  377    9.525   56.554  14.407
 LOCAL(0)        .LOCL.          13 l  39m   64    0    0.000    0.000   0.000
Here we had one dropped packet (375), but the last query was successful (number is odd). Now everything is valid and the peer reference source has switched to a better reachable server (lower delay and less jitter).

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1  7044  945a   yes   yes  none candidate    sys_peer  5
  2  7045  942a   yes   yes  none candidate    sys_peer  2
  3  7046  961a   yes   yes  none  sys.peer    sys_peer  1
  4  7047  941a   yes   yes  none candidate    sys_peer  1
  5  7048  941a   yes   yes  none candidate    sys_peer  1
  6  7049  80a3   yes    no  none    reject unreachable 10
  • assid: needed for the rv command
  • last_event: what the last event was
  • cnt: Count of events on this peer
ntpq -c rv
associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer,
version="ntpd 4.2.6p2@1.2194-o Sun Oct 17 13:45:13 UTC 2010 (1)",
processor="i686", system="Linux/2.6.32-5-686", leap=00, stratum=2,
precision=-22, rootdelay=7.690, rootdisp=39.820, refid=131.188.3.222,
reftime=d37b2394.a8cda9c7  Thu, Jun  7 2012 14:56:52.659,
clock=d37b23b8.e09741bd  Thu, Jun  7 2012 14:57:28.877, peer=7046, tc=7,
mintc=3, offset=27.075, frequency=-72.700, sys_jitter=5.200,
clk_jitter=11.243, clk_wander=5.488
This is your own status.

ntpq -c 'rv 7044'
associd=7044 status=941a conf, reach, sel_candidate, 1 event, sys_peer,
srcadr=ptbtime1.ptb.de, srcport=123, dstadr=213.239.214.170, dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000, rootdisp=0.244,
refid=PTB, reftime=d37b2b32.4360584e  Thu, Jun  7 2012 15:29:22.263,
rec=d37b2b32.ac64771f  Thu, Jun  7 2012 15:29:22.673, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=8, ppoll=8, headway=0, flash=00 ok,
keyid=0, offset=28.317, delay=21.835, dispersion=13.920, jitter=5.852,
xleave=0.015,
filtdelay=    22.04   22.15   22.47   24.85   25.06   22.91   26.58   21.84,
filtoffset=   40.74   36.38   32.51   29.43   27.94   29.21   29.09   28.32,
filtdisp=      0.00    4.02    8.06   11.97   15.87   19.88   21.83   23.79
This explains the "status" and how often the peer was unreachable etc.

Verifying your time

Use one of your queried timeservers for this. You should use this rarely, as if you only use this 1 time a day and 100 million other people do the same, this overloads the servers:
ntpdate -d ptbtime1.ptb.de.
 7 Jun 14:02:20 ntpdate[27886]: ntpdate 4.2.6p2@1.2194-o Sun Oct 17 13:45:14 UTC 2010 (1)
transmit(192.53.103.108)
receive(192.53.103.108)
transmit(192.53.103.108)
receive(192.53.103.108)
transmit(192.53.103.108)
receive(192.53.103.108)
transmit(192.53.103.108)
receive(192.53.103.108)
transmit(192.53.103.108)
server 192.53.103.108, port 123
stratum 1, precision -20, leap 00, trust 000
refid [PTB], delay 0.04823, dispersion 0.00049
transmitted 4, in filter 4
reference time:    d37b16c3.e903c37b  Thu, Jun  7 2012 14:02:11.910
originate timestamp: d37b16d2.eebfc838  Thu, Jun  7 2012 14:02:26.932
transmit timestamp:  d37b16d2.e8c8ca5a  Thu, Jun  7 2012 14:02:26.909
filter delay:  0.04823  0.05089  0.05051  0.04858
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.011368 0.010736 0.012201 0.011808
         0.000000 0.000000 0.000000 0.000000
delay 0.04823, dispersion 0.00049
offset 0.011368
An offset below 0.1s is very good.