[ntp:questions] Do logs indicate a config problem?

David L. Mills mills at udel.edu
Fri Jul 16 14:30:14 UTC 2010


Ulrich,

 From context I suspect Linux has incorporated the PPS kernel discipline 
code I wrote in the 1990s. That code has several provisions to groom 
noisy PPS signals, including a median filter, popcorn spike suppressor 
and range gate. Apparently, the PPS signal in this case is very noisy 
and these provisions are doing their job.

Dave

Ulrich Windl wrote:

>David Lord <snews at 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:
>>
>>
>>David
>>    
>>
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>http://lists.ntp.org/listinfo/questions
>  
>




More information about the questions mailing list