[ntp:questions] Re: limitation on the client time/date at ntp startup

Heiko Gerstung heiko.gerstung at meinberg.de
Wed Aug 23 05:19:51 UTC 2006


BG wrote:
> I can get ntp to run by typing in ntpd -n -g in a console window but
> for this application I don't want to keep a console window visible. Is
> there a way to automatically start ntp with the options and you see the
> service running in the services window?
> 


Our current Windows NTP installer (free) is capable of using the "-g"
option (the corresponding installer checkbox is labelled "allow big
initial timesteps"). But -g works only once, at startup. If you want to
show that you can change the time to 2003 and it is corrected
automagically, this won't work (ntp will exit and you have to restart it
yourself, losing all that "automagic" ...).

If you combine it with our free NTP Time Monitor - which can be set up
to automatically restart NTP in case it dies - your problem would be solved.

For your presentation I would use ntpdate and let it run once a minute
using the task scheduler of Windows ... :-)

Best regards,
Heiko



> 
> Richard B. Gilbert wrote:
>> BG wrote:
>>
>>> What is the limitation on the time difference of a client clock at ntp
>>> startup? Is it 1000 sec? Is there an option to increase this or a
>>> 'commercial' version of NTP that will allow greater differences? e.g.
>>> years
>>>
>>> I have a local network set up with a GPS connected to one pc acting as
>>> a ntp server. The GPS synchronizes the system clock of this pc. NTP
>>> distributes the time to another pc on the network. It appears that I
>>> can not change the client pc time/date more than 1000 sec or ntp will
>>> not correct the client clock.
>>>
>>> thank you
>>>
>> Then don't change the time on the client!!!  This is a non-issue in a
>> properly configure NTP network.
>>
>> The limit is 1024 seconds and I doubt that anyone is willing to change
>> it.  You can start ntpd on the client with the -g option and it will set
>> the client's clock on a one time basis.  Thereafter, ntpd should be able
>> to keep it synchronized.  If not, there is something very wrong with,
>> most probably, the client or (barely possible) the server.
>>
>> When ntpd is synchronizing the client, no one should be trying to change
>> the client's clock!!!
> 




More information about the questions mailing list