On 2012-02-15, Dave Hart <[email protected]> wrote: > 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
I think it depends. If it is pps that gpsd is reading, then I think the answer is yes. It either uses the nmea from the gps system to set the seconds of the pps or waits. I know the shmpps code does exactly that-- waits for the ntpq to report that the clock is synced with an offset of less than about 1.4 sec before sending pps pulses ( since it uses the system clock to determine the seconds part of the pps time) > 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
