Debian GNU/Linux testing Etch con ntp 4.2.0a.
Sul server si installano i pacchetti:
Nel file di configurazione /etc/ntp.conf si deve indicare qualche NTP server:
server ntps.net4u.it server pool.ntp.org server 127.127.1.0 fudge 127.127.1.0 stratum 13
Se il clock di sistema differisce da quello del server NTP di oltre 1000 secondi, il daemon ntpd muore indicando che si deve intervenire manualmente. Per ovviare a questo problema si può creare il cron job /etc/cron.d/ntpdate che una volta al giorno reimposta l'ora di sistema dal server NTP indipendentemente dalla differenza. Lo stesso script provvede anche a impostare l'orologio hardware dopo aver impostato quello di sistema.
#!/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin invoke-rc.d ntp-server stop invoke-rc.d ntpdate start invoke-rc.d ntp-server start
Appena riavviato il servizio con /etc/init.d/ntp-server restart il demone si sincronizza con il clock interno della macchina (server 127.127.1.0), ma annuncia uno stratum alto: 13. Quindi nei primi istanti di funzionamento il server non è adatto per la sincornizzazione dei client. Poi eventualmente si sincronizza con un server di stratum sufficientemente basso. Nel file di log si legge:
Dec 15 12:16:15 neon ntpd[10226]: precision = 3.000 usec Dec 15 12:16:15 neon ntpd[10226]: Listening on interface wildcard, 0.0.0.0#123 Dec 15 12:16:15 neon ntpd[10226]: Listening on interface wildcard, ::#123 Dec 15 12:16:15 neon ntpd[10226]: Listening on interface lo, 127.0.0.1#123 Dec 15 12:16:15 neon ntpd[10226]: Listening on interface eth0, 217.19.151.200#123 Dec 15 12:16:15 neon ntpd[10226]: kernel time sync status 0040 Dec 15 12:16:15 neon ntpd[10226]: frequency initialized -30.279 PPM from /var/lib/ntp/ntp.drift Dec 15 12:19:37 neon ntpd[10226]: synchronized to LOCAL(0), stratum 13 Dec 15 12:19:37 neon ntpd[10226]: kernel time sync disabled 0041 Dec 15 12:20:43 neon ntpd[10226]: synchronized to 80.83.192.129, stratum 2 Dec 15 12:23:50 neon ntpd[10226]: kernel time sync enabled 0001
Lo stato del server si interroga sul server stesso con:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ramses.net4u.it 192.53.103.103 2 u 40 64 377 24.119 -5.678 1.855
+qnan.org 192.5.41.41 2 u 40 64 377 179.912 -12.773 1.859
LOCAL(0) LOCAL(0) 13 l 41 64 377 0.000 0.000 0.004
Riportiamo dalla pagina NTP Overview una spiegazione dell'output del comando.
remote refid st t when poll reach delay offset jitter ======================================================================= LOCAL(0) LOCAL(0) 12 l 30 64 377 0.000 0.000 0.000 *GENERIC(0) .DCFa. 0 - 24 64 377 0.000 0.050 0.003 +172.16.3.103 .PPS. 1 u 36 64 377 1.306 -0.019 0.043
If the first character of a line is not blank then it contains a qualifier for the corresponding reference time source. Immediately after the daemon has been started all qualifiers are blank. The NTP daemon needs several polling cycles to check the available time sources and declare one of them as the reference it synchronizes to.
An asterisk * in the first column marks the reference time source which is currently preferred by the NTP daemon, the + character marks high quality candidates for the reference time which could be used if the currently selected reference time source should become unavailable.
The column remote displays the IP address or the host name of the reference time source, where LOCAL refers to the local clock. The refid shows the type of the reference clock, where e.g. LOCAL or LCL refers to the local clockagain, .DCFa. refers to a standard DCF77 time source, and .PPS. indicates that the reference clock is disciplined by a hardware pulse-per-second signal. Other identifiers are possible, depending on the type of the reference clock.
The column st reflects the stratum number of the reference time source. In the example above, the local clock has stratum 12, the remote time server at 172.16.3.103 has stratum 1 which is the best you can see across the network, and the local radio clock has stratum 0, so the radio clock is currently being preferred.
Every time a when count reaches the poll number in the same line, the NTP daemon queries the time from the corresponding time source and resets the when count to 0. The query results of each polling cycle are filtered and used as a measure for the clock's quality and reachability.
The column reach shows if a reference time source could be reached at the last polling intervals, i.e. data could be read from the reference time source, and the reference time source was synchronized. The value must be interpreted as an 8 bit shift register whose contents is for historical reasons displayed as octal values. If the NTP daemon has just been started, the value is 0. Each time a query was successful a '1' is shifted in from the right, so after the daemon has been started the sequence of reach numbers is 0, 1, 3, 7, 17, 37, 77, 177, 377. The maximum value 377 means that the eight last queries were completed successfully.
Queries are considered successful if data can be received from the time source, and the time source in turn claims to be synchronized to some other timesource. In case of a hardware reference clock this means the query considered unsuccessful if the hardware reference clock is not synchronized to its incoming time signal, e.g. because the clock's antenna has been disconnected, or if no data can be received e.g. because the serial cable to an external device has been disconnected.
The NTP daemon must have reached a reference time source several times (reach not 0) before it selects a preferred time source and puts an asterisk in the first column.
The columns delay, offset and jitter show some timing values which are derived from the query results. In some versions of ntpq the last column is labeled disp (for dispersion) instead of jitter. All values are in in milliseconds. The delay value is derived from the roundtrip time of the queries. The offset value shows the difference between the reference time and the system clock. The jitter value indicates the magnitude of jitter between several time queries.
Sul client si può sincronizzare l'orologio con ntpdate e fare il debug con ntpdate -d. Ecco un debug di fallimento:
# ntpdate -d ntp.texnet.it
15 Dec 12:19:03 ntpdate[4612]: ntpdate 4.2.0a@1:4.2.0a+stable-2-r Fri Aug 26 10:30:13 UTC 2005 (1)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
217.19.151.200: Server dropped: strata too high
server 217.19.151.200, port 123
stratum 16, precision -18, leap 11, trust 000
refid [217.19.151.200], delay 0.02591, dispersion 0.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: c74bcfa7.c9737542 Thu, Dec 15 2005 12:19:03.786
transmit timestamp: c74bcfa7.a08bc9cd Thu, Dec 15 2005 12:19:03.627
filter delay: 0.02608 0.02592 0.02592 0.02591
0.00000 0.00000 0.00000 0.00000
filter offset: 0.159672 0.159616 0.159610 0.159614
0.000000 0.000000 0.000000 0.000000
delay 0.02591, dispersion 0.00000
offset 0.159614
15 Dec 12:19:03 ntpdate[4612]: no server suitable for synchronization found
Ecco invece una situazione funzionante:
ulisse:~# ntpdate -d ntp.texnet.it
15 Dec 12:38:35 ntpdate[4677]: ntpdate 4.2.0a@1:4.2.0a+stable-2-r Fri Aug 26 10:30:13 UTC 2005 (1)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
receive(217.19.151.200)
transmit(217.19.151.200)
server 217.19.151.200, port 123
stratum 3, precision -18, leap 00, trust 000
refid [217.19.151.200], delay 0.02594, dispersion 0.00000
transmitted 4, in filter 4
reference time: c74bd411.79bc44bf Thu, Dec 15 2005 12:37:53.475
originate timestamp: c74bd43b.82be596c Thu, Dec 15 2005 12:38:35.510
transmit timestamp: c74bd43b.919988d2 Thu, Dec 15 2005 12:38:35.568
filter delay: 0.02609 0.02596 0.02594 0.02597
0.00000 0.00000 0.00000 0.00000
filter offset: -0.05817 -0.05821 -0.05822 -0.05823
0.000000 0.000000 0.000000 0.000000
delay 0.02594, dispersion 0.00000
offset -0.058220
15 Dec 12:38:35 ntpdate[4677]: adjust time server 217.19.151.200 offset -0.058220 sec