Ulrich Windl wrote:
David Lord <sn...@lordynet.org> writes:

Do logs indicate a config problem?

system  server1:  MSFa, PPSa peer=server2 and remote servers
system  server2:  peer=server1 and remote servers
system  server3:  GPSb, PPSb, server2 and server1


This is total logged over period Feb 7 to Feb 12:
ntp.log.server1:
 7 Feb 19:22:39 ntpd[26820]: clock SHM(0) event 'clk_noreply' (0x01)
 7 Feb 19:22:40 ntpd[26820]: clock PPS(0) event 'clk_noreply' (0x01)
 7 Feb 19:27:01 ntpd[26820]: synchronized to SHM(0), stratum 0
 7 Feb 19:27:01 ntpd[26820]: kernel time sync status change 2001
 7 Feb 19:28:01 ntpd[26820]: synchronized to PPS(0), stratum 0
12 Feb 10:13:44 ntpd[26820]: sendto(xxx.xxx.xx.xx) (fd=27): Host is down
12 Feb 10:20:41 ntpd[26820]: ntpd exiting on signal 15


This is tiny section of log on server1 with similar entries
repeating continuously over whole period Feb 12 to Feb 14. There
were too many reboots and restarts over period for peerstats to
be useful. I swapped kernels attempting to get frequency offset
down from just over 50ppm but the autoconfig still gave 50ppm
(on NetBSD-3.1 I could set "options TIMER_FREQ=" to  get < 10ppm
without problem).

ntp.log.server1:
13 Feb 07:07:48 ntpd[22483]: kernel time sync status change 2901
13 Feb 07:08:53 ntpd[22483]: kernel time sync status change 2101
13 Feb 07:09:59 ntpd[22483]: kernel time sync status change 2301
13 Feb 07:17:28 ntpd[22483]: kernel time sync status change 2501
13 Feb 07:18:32 ntpd[22483]: kernel time sync status change 2301
13 Feb 07:19:38 ntpd[22483]: kernel time sync status change 2901
13 Feb 07:20:41 ntpd[22483]: kernel time sync status change 2301
13 Feb 07:21:47 ntpd[22483]: kernel time sync status change 2101
13 Feb 07:22:50 ntpd[22483]: kernel time sync status change 2501
13 Feb 07:23:54 ntpd[22483]: kernel time sync status change 2101

from timex.h:
0x0001 enable pll updates
0x0002 enable pps freq discipline
0x0004 enable pps time discipline
0x0100 pps signal present
0x0200 pps signal jitter exceeded
0x0400 pps signal wander exceeded
0x0800 pps signal calibration error

Hi!

I'd say all 0x800 and 0x400 should never happen unless there is a severe
problem. 0x200 should also happen extremely rarely under normal
conditions. (based on my NTP/Linux experience several years ago)

Regards,
Ulrich


This is total logged over period Feb 14 to Feb 19:
ntp.log.server1
14 Feb 10:49:34 ntpd[169]: clock SHM(0) event 'clk_noreply' (0x01)
14 Feb 10:52:53 ntpd[169]: synchronized to xx.xxx.xx.xxx, stratum 2
14 Feb 10:52:53 ntpd[169]: kernel time sync status change 2001
14 Feb 10:58:05 ntpd[169]: synchronized to SHM(0), stratum 0
15 Feb 10:32:40 ntpd[169]: ntpd exiting on signal 15
15 Feb 10:34:00 ntpd[169]: clock SHM(0) event 'clk_noreply' (0x01)
15 Feb 10:40:27 ntpd[169]: synchronized to xx.xxx.xx.xxx, stratum 2
15 Feb 10:40:27 ntpd[169]: kernel time sync status change 2001
15 Feb 10:41:47 ntpd[169]: synchronized to xx.xxx.xx.xxx, stratum 2
15 Feb 10:42:36 ntpd[169]: synchronized to SHM(0), stratum 0


This is tiny section of log on server3 with similar entries
repeating continuously over whole period Feb 7 to Feb 19.
ntp.log.server3:
19 Feb 13:08:24 ntpd[6745]: kernel time sync error \

0x2307<PLL,PPSFREQ,PPSTIME,PPSSIGNAL,PPSJITTER,NANO,MODE=0x0=PLL,CLK=0x0=A>
19 Feb 13:08:39 ntpd[6745]: kernel time sync status change \
0x2107<PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO,MODE=0x0=PLL,CLK=0x0=A>
19 Feb 13:13:31 ntpd[6745]: kernel time sync error \

0x2307<PLL,PPSFREQ,PPSTIME,PPSSIGNAL,PPSJITTER,NANO,MODE=0x0=PLL,CLK=0x0=A>
19 Feb 13:13:46 ntpd[6745]: kernel time sync status change \
 0x2107<PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO,MODE=0x0=PLL,CLK=0x0=A>



Otherwise timekeeping is good enough for me:

peerstats
                             ident     mean     rms      max
==========================================================================
..... MSF using serial dsr with shm and pps to serial dcd with atom
server1  20100208-11    127.127.22.0    0.045    1.038    7.100 PPSa
server3  20100208-11    127.127.22.0   -0.043    0.288    4.544 PPSb
server3  20100208-11    server1         0.031    0.416    3.485
server3  20100208-11    server2         0.422    0.577    5.196
..... MSF config changed to use only serial dcd with shm driver
server1  20100215-18    127.127.28.0    0.197    0.427    2.723  MSFa
server3  20100215-18    127.127.22.0    0.000   -0.002    0.021  PPSb
server3  20100215-18    server1         1.371    0.412    1.139
server3  20100215-18    server2         1.452    0.504    1.222


Offset from MSF receiver varies significantly with temperature,
around 1ms/deg based on offset of server1 seen from server3 and
corresponding to similar offset variation vs remote servers.

GPSb/PPSb on server3 isn't usable from current location of aerial
in bad weather eg. on 8th 9th when signal lost for short periods
significantly skewing the stats above:


I can't remember the exact cause unless I go back through
logs for that period but I think serial DCD was still being
used even though I had only parallel PPS. I'd not tried
parallel pps before and it requires various changes to
kernel config and a recompile (in this cases several tries
before had it working).

When I gave the parallel PPS a different device number the
problem went away, although I was making other changes at same
time. There may have been interactions between devices  LPT
and PPS devices in kernel. The ntp.log entries after that were
periodic "kernel time sync status change 2001" alternated with
"kernel time sync status change 6001"

I currently had lots of benign errors from a watch xtal
refclock I'd disconnected but on restart of ntpd with those
server and fudge lines removed from ntp.conf the log looks ok.

16 July
09:56:27 ntpd exiting
09:56:39 clock PPS(2) event clk_noreply
10:01:01 synch to GPS_NMEA(2), stratum 0
10:01:01 kernel time sync status change 0x2101
10:02:02 kernel time sync status change 0x2107
10:02:17 synchronized to PPS(2), stratum 0

and "ntpq -p" gives PPS(2) offset 0.000ms and
other servers on lan < 1.4ms.


David

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to