On Fri, 8 Dec 2006, Arthur Konovalov wrote: > Hi! > > Noticed periodical messages in logfile: > > Dec 8 11:33:38 time ntpd[7000]: kernel time sync disabled 2307 > Dec 8 11:33:55 time ntpd[7000]: kernel time sync enabled 2107 > Dec 8 11:42:56 time ntpd[7000]: kernel time sync disabled 2307 > Dec 8 11:43:13 time ntpd[7000]: kernel time sync enabled 2107 > Dec 8 11:48:21 time ntpd[7000]: kernel time sync disabled 2307 > Dec 8 11:48:36 time ntpd[7000]: kernel time sync enabled 2107 > > From status bits I understand that it means "PPS signal jitter exceed", > but why? > Is it normal (safe)? How to found reason? > > Using Garmin GPS18 LVC, FreeBSD 4.2, ntpd 4.2.0-a > > time# ntpq -p > remote refid st t when poll reach delay offset > jitter > ============================================================================== > *GPS_NMEA(1) .PPS. 0 l 6 16 377 0.000 0.001 > 0.004 > > > Regards, > AK > > _______________________________________________ > timekeepers mailing list > [email protected] > https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers >
Hello Arthur, I have no experience at all with stratum 0 devices like GPSs. But as my two cents, here is how I understand it : kernel time sync disabled: ntpd doesn't sync kernel time anymore. kernel time sync enabled: ntpd is back to syncing kernel time. I had repetitive kernel time sync outputs in my logs while testing with bad source servers that returned too much offset for ntpd to keep syncing kernel time. So, as far I understand it, it doesn't mean your GPS setup is wrong. It just means that ntpd quit syncing the kernel time for a while. I believe it is not fatal to loose kernel sync once in a while. It mostly depends on how long you loose kernel sync for. Say loosing kernel sync for a few seconds shouldn't hurt much the reliability of your time server unless ntpd quit serving requests when that happens, which I am not sure of... During those seconds, the kernel just keeps time on itself, which should be fine. My main ntp server ALWAYS loose kernel sync for a few seconds when restarted, after connecting to stratum 1 servers. Before connecting to the stratum 1 servers it took its time from the local clock which was too far away from the average result returned by the stratum 1 servers. (I use iburst on my ISP servers) Also, since you have no backup stratum 1 servers for ntpd to rely on. Ntpd should loose kernel sync at the smallest transitory glitch on the link between the GPS and the computer or the GPS device itself. With backup stratum 1 servers configured, ntpd would rely on them to keep kernel sync (no more loosing kernel sync) when a small GPS glitch occurs. Others with deeper knowledge of ntpd can correct me if I am wrong and they can also be more specific. This was just my two cents, hope it helped. I am quite positive although than adding backup stratum one servers to your config would help you, unless your onboard oscillator generating the interrupts for the "loop" is defective, of course ;-) Again, others are invited to correct me if I am wrong ! Louis _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
