[ntp:questions] ntpd -g option

Echols Jr, Thomas tommy.echols at cubic.com
Tue Feb 21 20:00:07 UTC 2012

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?


-----Original Message-----
From: Dave Hart [mailto:hart at ntp.org] 
Sent: Wednesday, February 15, 2012 11:08 AM
To: Echols Jr, Thomas
Cc: questions at lists.ntp.org
Subject: Re: [ntp:questions] ntpd -g option

On Tue, Feb 14, 2012 at 16:54, Echols Jr, Thomas <tommy.echols at cubic.com> 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

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:


Dave Hart

More information about the questions mailing list