[ntp:questions] NTPD 4 hours off date problem

X.B. xbntp at mailinator.com
Tue May 10 08:37:28 UTC 2005

Brad Knowles a écrit :
> At 3:45 PM +0200 2005-05-09, X.B. wrote:
>>  The computer i'm using has no cmos battery, so each time it is cold
>>  rebooted, the internal clock is set to something around 01-01-2000.
>>  In this case, ntpd -g -q cannot set up the date correctly.
>>  Nor can ntpd -g ...
>     There is a 1000 second sanity check, and if you're outside of that 
> then ntpd will refuse to start.  However, this can be over-ridden with 
> the "-g" option.  At that point, you should be able to use ntpd to sync 
> your time regardless of how far off your system clock is.
>     If that's not working, I think you've got much more serious problems.
>>  I've gone through the source code, and found that antenna's NTP packets
>>  are thrown out (1) because the date they contain is more than 4 hours
>>  (CLOSETIME 4*60*60) off the system date ... So ntpd refuse to set the 
>> date.
>     Precisely where in the code are you seeing this?

The check on received packet ( if i understand correctly ... ) is made 
in clocktime.c:clocktime().

In my case, clocktime() is called from ntp_refclock.c:refclock_process() 
on line 439 calls.

As said upper, ntpd cannot work as the packets seems to be thrown out 
before even the 1000s sanity check is done. That's why -g and -q are of 
no use.

About other responses : Thanks for you all !

 From what i read from your ( fast! ) responses
i'll need to make a hack, in or out of ntp, to force the clock somewhere.

I this case, using the CMOS clock is not an option ( i know, i know ... 
), nor using a file date ( i cannot know how long the computer will be 
powered off, and due to the +-4 hours validity range ...

I'm not sure if it is a good idea, but what about suppressing the test 
against CLOSETIME from clocktime when '-g' option is set
that is, extending the 'effect' of the -g option to clocktime :
- 1st packet check do NOT check against CLOSETIME.
- Following packets are fully checked

Or may be ignoring colcktime errors from caller(s) when -g is used 
(allow_panic) ?

More information about the questions mailing list