[ntp:questions] problem with a failsafe setup, hardware clocks and the correctness test

Eike Middell eike at middell.net
Tue Aug 14 15:04:49 UTC 2007


Hi, 
thanks for your reply.

localhost.localdomain (host B) is the host with the gps clock and which runs a cronjob 
that dumps the output of ntpq into a file.
192.168.5.1 (host A) is the host with the connection to the internet. 

Host B should synchronize to host A if the gps-card fails.


Mon Aug 13 00:11:01 UTC 2007
host                       remote           refid      st t when poll reach   delay   offset  jitter
====================================================================================================
localhost.localdomain  LOCAL(0)        LOCAL(0)        10 l    9   64 377    0.000    0.000   0.001
localhost.localdomain *GENERIC(0)      .GPSi.           0 l   38   64 377    0.000   -0.072   0.002
localhost.localdomain x192.168.5.1     130.149.17.21    2 u    2   64 377    0.250   28.875   0.113
host                       remote           refid      st t when poll reach   delay   offset  jitter
====================================================================================================
192.168.5.1            ntp0-rz.rrze.un .STEP.          16 u    - 1024 0    0.000    0.000 4000.00
192.168.5.1           *ntps1-0.cs.tu-b .PPS.            1 u  977 1024 377  806.382  110.220  16.160
192.168.5.1            ptbtime1.ptb.de .STEP.          16 u    - 1024 0    0.000    0.000 4000.00
192.168.5.1            clock.via.net   .STEP.          16 u    - 1024 0    0.000    0.000 4000.00
192.168.5.1            LOCAL(0)        LOCAL(0)        13 l   37   64 377    0.000    0.000   0.002

## a bad reply from the host A's reference lets it switch to the local clock

Mon Aug 13 00:12:01 UTC 2007
host                       remote           refid      st t when poll reach   delay   offset  jitter
====================================================================================================
localhost.localdomain  LOCAL(0)        LOCAL(0)        10 l    4   64 377    0.000    0.000   0.001
localhost.localdomain *GENERIC(0)      .GPSi.           0 l   34   64 377    0.000   -0.072   0.001
localhost.localdomain x192.168.5.1     130.149.17.21    2 u   61   64 377    0.250   28.875   0.113
host                       remote           refid      st t when poll reach   delay   offset  jitter
====================================================================================================
192.168.5.1            ntp0-rz.rrze.un .STEP.          16 u    - 1024 0    0.000    0.000 4000.00
192.168.5.1            ntps1-0.cs.tu-b .PPS.            1 u   13 1024 377  6479.89  2946.77 1660.95
192.168.5.1            ptbtime1.ptb.de .STEP.          16 u    - 1024 0    0.000    0.000 4000.00
192.168.5.1            clock.via.net   .STEP.          16 u    - 1024 0    0.000    0.000 4000.00
192.168.5.1           *LOCAL(0)        LOCAL(0)        13 l   32   64 377    0.000    0.000   0.002

## following that, host A rejects the gps-card and switches to it's only remaining reference

Mon Aug 13 00:13:01 UTC 2007
host                       remote           refid      st t when poll reach   delay   offset  jitter
====================================================================================================
localhost.localdomain *LOCAL(0)        LOCAL(0)        10 l   64   64  377    0.000    0.000   0.001
localhost.localdomain xGENERIC(0)      .GPSi.           0 l   31   64  377    0.000   -0.055   0.018
localhost.localdomain x192.168.5.1     LOCAL(0)        14 u   43   64  377    0.264   30.128   0.006
host                       remote           refid      st t when poll reach   delay   offset  jitter
====================================================================================================
192.168.5.1            ntp0-rz.rrze.un .STEP.          16 u    - 1024    0    0.000    0.000 4000.00
192.168.5.1            ntps1-0.cs.tu-b .PPS.            1 u   73 1024  377  6479.89  2946.77 1660.95
192.168.5.1            ptbtime1.ptb.de .STEP.          16 u    - 1024    0    0.000    0.000 4000.00
192.168.5.1            clock.via.net   .STEP.          16 u    - 1024    0    0.000    0.000 4000.00
192.168.5.1           *LOCAL(0)        LOCAL(0)        13 l   29   64  377    0.000    0.000   0.002



## The configuration file for host A:

logfile /var/log/ntpd.log

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
logconfig syncall +clockall +peerall +sysall

server ntps1-0.uni-erlangen.de burst
server ntps1-0.cs.tu-berlin.de burst
server ptbtime1.ptb.de burst
server clock.via.net

# ... and use the local system clock as a reference if all else fails
# NOTE: in a local network, set the local stratum of *one* stable server
# to 10; otherwise your clocks will drift apart if you lose connectivity.
server 127.127.1.0
fudge 127.127.1.0 stratum 13

# some tinker settings, commented values have their standard-value
#tinker step 0.128
tinker panic 0.  # no offset is to big -> never panic
#tinker dispersion .000015
#tinker stepout 900
#tinker huffpuff 7200
#tinker minpoll 6
#broadcastdelay  0.008

# By default, exchange time with everybody, but don't allow configuration.
# See /usr/share/doc/ntp-doc/html/accopt.html for details.
restrict default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1 nomodify

# Allow others in our subnet to check us out...
restrict 192.168.5.0  mask 255.255.255.0 nomodify



## The configuration file for host B:

# set to stratum 10 to be the very last source for synchronization
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10  

# Meinberg GPS169PCI 
server 127.127.8.0 mode 2 prefer
fudge 127.127.8.0 time1 0.0
fudge 127.127.8.0 refid GPSi

# other NTP servers
server 192.168.5.1 burst

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp.drift
broadcastdelay  0.008   # compensate for a slow network. really needed?

# set access control
restrict default ignore notrust nomodify        # ignore anyone except those listed below
restrict 127.0.0.1                                                      # allow anything from localhost
restrict 192.168.5.0 mask 255.255.255.0 nomodify        # allow our trusted computers to connect
restrict 192.168.3.0 mask 255.255.255.0 nomodify        # allow the tourists to connect
restrict ntps1-0.uni-erlangen.de nomodify
restrict ntps1-0.cs.tu-berlin.de nomodify
restrict ptbtime1.ptb.de nomodify

# generate as much logging information as possible
statistics loopstats clockstats peerstats
statsdir /var/log/ntp/stats/
filegen peerstats file peers type day enable
filegen loopstats file loops type day enable
filegen clockstats file clocks type day enable

logconfig syncall +clockall +peerall +sysall
logfile /var/log/ntp/ntpd.log



Best regards,
Eike



On Mon, Aug 13, 2007 at 05:06:38PM -0400, Danny Mayer wrote:
> Eike Middell wrote:
> > Hi again,
> > maybe I should clarify my problem with this situation. 
> > 
> > In the documentation the local clock driver is presented as a useful
> > reference for the case that all other references fail. (see:
> > http://www.ee.udel.edu/~mills/ntp/html/drivers/driver1.html second
> > paragraph)
> > 
> > But what I'm observing is that although my two hardware clocks in
> > the network are given high stratum numbers and the gps-clock is running
> > flawlessly the hardwareclocks can outrival the gps-clock through 
> > the backdoor of the correctness test! This contradicts the basic idea
> > that the stratum level is the measure for the quality of the clock.
> > (e.g. stated in the cited paragraph above) and that the so defined
> > hierarchy dictates the clock selection.
> > 
> > So what I would like to know is whether anybody experienced a similar  
> > situation? If this is regarded normal behaviour are there other pitfalls 
> > where the hierarchy given by stratum levels is ignored?
> > 
> 
> No, there's something wrong. Please post output from ntpq -p and your
> configuration file.
> 
> Danny



More information about the questions mailing list