[ntp:questions] Reference Clock / shared memory driver

stuart clark stuart.clark at baesystems.com
Thu Jan 29 04:37:20 UTC 2009


On Jan 29, 1:26 pm, "Richard B. Gilbert" <rgilber... at comcast.net>
wrote:
> stuart clark wrote:
> > I have a server 127.127.28.2 prefer minpoll 4 entry in my ntp.conf
> > file. i have no other server entries in the ntp.conf file. This server
> > entry creates a shared memory segment on startup with a defined shared
> > memory "key".
>
> > I have an application which i start manually which uses the "key" to
> > write a shmTime value to, see(http://www.eecis.udel.edu/~mills/ntp/
> > html/drivers/driver28.html). The app is correctly setting the valid
> > and count fields when it updates the shmTime value.
>
> > I use a system clock time from another application via a 1553 bus from
> > another machine to set clockTimeStamp and receiveTimeStamp fields.
>
> > i have debug code in my app which writes to standard out when the
> > valid field has been cleared, ie ntpd has read the shared memory
> > segment. The rate at which this vlid field is cleared is correct, at
> > 16 seconds (this set by the minpoll 4 param ,ie 2**4).
>
> > The problem is do NOT see my system clock being updated after the ntpd
> > has read the shared memory getment.
>
> > As i am completely new to ntpd i have struggled thru the man pages
> > etc.
>
> > Question 1 = Am i correct in saying i think the problem is the
> > difference in the two machine clocks is greater than 128 ms. from the
> > man pages i understand ntpd wont adjust a clock if the time diff is
> > more than +- 128 ms.
>
> If the clock is off by too great an amount you can force ntpd to set the
> clock on a once only basis by using "ntpd -g".
>
> > Question 2 = i can/have used the ntpdate command to sync the two
> > system clocks. to do this on the server machine i start the ntpd, but
> > on the client machine i call ntpdate BEFORE i start the ntpd. now the
> > problem is verifying any differences of less than 128 are being
> > corerectly adjusted on the client machine.
>
> This will work but ntpd -g does pretty much the same thing with one
> command instead of two.
>
> Is there some reason to believe that the client machine is NOT adjusting
> its clock correctly?  You can run ntpdate with the -D option while ntpd
> is running and it will tell you what correction it would apply to the
> clock at the instant you asked.  Note that ntpdate is deprecated!
>
> Also note that ntpd needs at least thirty minutes after a cold start to
> beat the clock into submission!  Depending on how cold the cold start
> was it may take longer; e.g. if you've been storing your computer in an
> unheated garage with the temperatures below -20 degrees F, ntpd might
> need 24 hours or more to settle down to really accurate time keeping.
> The moral of this story is "don't shut it down".  The second moral is,
> if you MUST shut it down, don't believe the time until the temperature
> has been stable for several hours.- Hide quoted text -
>
> - Show quoted text -


 Is there some reason to believe that the client machine is NOT
adjusting
> its clock correctly?  You can run ntpdate with the -D option while ntpd
> is running and it will tell you what correction it would apply to the
> clock at the instant you asked.  Note that ntpdate is deprecated!


Thanks for the info.

I have tried using the -g option and for a "standard" 192.168.1.10
server with the client clock manually adjusted one hour in front of
the server machine's After about a minute and a half the client clock
is updated to match the server. However i dont have the same luck
using the shared memory driver.

i have added the option dynamic to the shared memory version, ie
server 192.168.1.10 prefer minpoll 4 dynamic in the ntp.conf but with
no luck.

Any ideas???




More information about the questions mailing list