The document provides instructions for basic NTP configuration and monitoring. It recommends configuring at least two NTP servers, with one acting as primary and the other as backup. It also advises creating a drift file to help NTP learn the system clock's error rate. Various utilities like ntpq, ntpdc, ntptime and ntpdate can be used to check NTP synchronization and determine any offset from the remote server time.

1. Basic NTP configuration

2. # --- GENERAL CONFIGURATION ---
server aaa.bbb.ccc.ddd
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# Drift file.
driftfile /etc/ntp/drift

3. The most basic ntp.conf file will simply list 2 servers, one that it wishes to synchronize with, and
a pseudo IP address for itself (in this case 127.127.1.0). The pseudo IP is used in case of network
problems or if the remote NTP server goes down. NTP will synchronize against itself until the it
can start synchronizing with the remote server again. It is recommended that you list at least 2
remote servers that you can synchronize against. One will act as a primary server and the other
as a backup.
You should also list a location for a drift file. Over time NTP will "learn" the system clock's error
rate and automatically adjust for it.
The restrict option can be used to provide better control and security over what NTP can do, and
who can effect it. For example:

4. # Prohibit general access to this service.
restrict default ignore
# Permit systems on this network to synchronize with this
# time service. But not modify our time.
restrict aaa.bbb.ccc.ddd nomodify
# Allow the following unrestricted access to ntpd
restrict aaa.bbb.ccc.ddd
restrict 127.0.0.1

5. It is advised that you wait until you have NTP working properly before adding the restrict option. You can accidental restrict yourself from
synchronizing and waste time debugging why.
NTP slowly corrects your systems time. Be patient! A simple test is to change your system clock by 10 minutes before you go to bed and
then check it when you get up. The time should be correct.
Many people get the idea that instead of running the NTP daemon, they should just setup a cron job job to periodically run the ntpdate
command. There are 2 main disadvantages of using using this method.
The first is that ntpdate does a "brute force" method of changing the time. So if your computer's time is off my 5 minutes, it immediately
corrects it. In some environments, this can cause problems if time drastically changes. For example, if you are using time sensitive security
software, you can inadvertently kill someones access. The NTP daemon slowly changes the time to avoid causing this kind of disruption.
The other reason is that the NTP daemon can be configured to try to learn your systems time drift and then automatically adjust for it.

6. NTP Toolkit
There are a number of utilities available to check if NTP is doing it's job. The ntpq -p command
will print out your system's current time status.
The ntpdc -c loopinfo will display how far off the system time is in seconds, based upon the last
time the remote server was contacted.

7. # ntpdc -c loopinfo
offset: -0.004479 s
frequency: 133.625 ppm
poll adjust: 30
watchdog timer: 404 s

8. ntpdc -c kerninfo will display the current
remaining correction.
# ntpdc -c kerninfo
pll offset: -0.003917 s
pll frequency: 133.625 ppm
maximum error: 0.391414 s
estimated error: 0.003676 s
status: 0001 pll
pll time constant: 6
precision: 1e-06 s
frequency tolerance: 512 ppm
pps frequency: 0.000 ppm
pps stability: 512.000 ppm
pps jitter: 0.0002 s
calibration interval:4 s
calibration cycles: 0
jitter exceeded: 0
stability exceeded: 0
calibration errors: 0

9. A slightly more different version of ntpdc
-c kerninfo is ntptime
# ntptime
ntp_gettime() returns code 0 (OK)
time c35e2cc7.879ba000 Thu, Nov 13 2003 11:16:07.529, (.529718),
maximum error 425206 us, estimated error 3676 us
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -3854.000 us, frequency 133.625 ppm, interval 4 s,
maximum error 425206 us, estimated error 3676 us,
status 0x1 (PLL),
time constant 6, precision 1.000 us, tolerance 512 ppm,
pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us,
intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.

10. Yet another way to see how well NTP is working is with the ntpdate-d command. This will contact an
NTP server and determine the time difference but not change your system's time.
# ntpdate -d 132.236.56.250
13 Nov 14:43:17 ntpdate[29631]: ntpdate 4.1.1c-rc1@1.836Thu Feb 13 12:17:20 EST 2003 (1)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
server 132.236.56.250, port 123
stratum 2, precision -17, leap 00, trust 000
refid [192.5.41.209], delay 0.06372, dispersion 0.00044
transmitted4, in filter4
reference time: c35e5998.4a46cfc8 Thu, Nov 13 2003 14:27:20.290
originatetimestamp: c35e5d55.d69a6f82 Thu, Nov 13 2003 14:43:17.838
transmit timestamp: c35e5d55.d16fc9bc Thu, Nov 13 2003 14:43:17.818
filter delay: 0.06522 0.06372 0.06442 0.06442
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000036 0.001020 0.000527 0.000684
0.000000 0.000000 0.000000 0.000000