I was wondering if the -g option with ntp is only good when using time servers. Currently I am running a system that uses a GPS and a radio as time sources and ntp keeps the system time in sync. However if the system time is too far off, say a few years, it is my understanding that with a -g, the system time should be adjusted to the current time as long as it is within 64 years of the current date. This is not happening. When I stop ntp and run it in debug mode the following messages are printed which is why the clock never syncs up.
refclock_transmit: at 1 127.127.28.0 event at 1 SHM(0) 801b 8b clock_event clk_no_reply event at 2 SHM(0) 801b 8b clock_event clk_bad_time refclock_transmit: at 2 127.127.28.4 event at 1 SHM(4) 801b 8b clock_event clk_no_reply event at 2 SHM(4) 801b 8b clock_event clk_bad_time when the time is manually adjusted to a closer to actual time this is what the debug message looks like: event at 17 SHM(0) 8044 84 reachable refclock_sample: n 16 offset 0.000295 disp 0.000000 jitter 0.000031 clock_filter: n 1 off 0.000295 del 0.000000 dsp 7.937515 jit 0.000031 select: combine offset 0.000294622 jitter 0.000030518 clock_update: at 17 sample 17 associd 782 Does anyone know why this would occur? Will a -g option not work with a Shared memory time source, or is there something else that needs to be done in tandem. Below is my ntp.conf file: driftfile /var/run/ntp.drift #server pool.ntp.org # By default, exchange time with everybody, but don't allow configuration. restrict -4 default kod notrap nomodify nopeer noquery #restrict -6 default kod notrap nomodify nopeer noquery # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 #restrict ::1 server 127.127.28.0 minpoll 4 fudge 127.127.28.0 refid gpsd server 127.127.28.4 minpoll 4 fudge 127.127.28.4 refid radio -Tommy _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
