On Jan 29, 1:26 pm, "Richard B. Gilbert" <[email protected]> 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??? _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
