Hey Dave, Thanks for the response. I tried the patch and didn't seem to have any luck. I wrote a program that checks out what is in the shared memory, and the valid flag is being set by both shared reference clocks, one being gpsd and the other being a radio. The time stamps being received are also valid, so my only conclusion to make is that ntp is rejecting the times because they are several years ahead of the system clock. When the system clock is set to something closer to the times coming in from the reference clocks, ntp will recognize them and sync the clock which means the -g option isn't doing what I would expect. Any other thoughts on to why this would be?
-Tommy -----Original Message----- From: Dave Hart [mailto:[email protected]] Sent: Wednesday, February 15, 2012 11:08 AM To: Echols Jr, Thomas Cc: [email protected] Subject: Re: [ntp:questions] ntpd -g option On Tue, Feb 14, 2012 at 16:54, Echols Jr, Thomas <[email protected]> wrote: > 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: ntpd -g behavior is the same for reference clocks and upstream NTP servers. The timeout happens when the shared memory segment's valid field is zero. Bad time is triggered by incredible date or time values. I wonder if gpsd is requiring the time be close before sharing it with ntpd. Miroslav Lichvar has a patch pending to add support to refclock_shm.c to report a timecode string in response to ntpq's cv, you might give that a whirl: http://bugs.ntp.org/2048 Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
