Richard B. Gilbert wrote:
> Unruh wrote:
>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>
>>> Unruh wrote:
>>>> "Richard B. Gilbert" <[EMAIL PROTECTED]> writes:
>>>>
>>>>
>>>>> There are other tools than NTPD.  One called "chrony" MAY meet your 
>>>>> needs, or may not.  NTPD is very good at working over the Internet 
>>>>> with its unpredictable queuing delays.  Chrony, as I understand it, 
>>>>> is not so good at working over the internet.
>>>> No idea where you get this from. chrony works over the internet at 
>>>> least as
>>>> well as does ntpd. Its philosophy of dealing with different delays is
>>>> different than ntp's( although it can be set up to be virtually 
>>>> identical)
>>>>
>>>>
>>>>> If you can't keep your machines up 24x7, chrony MAY be a better 
>>>>> tool. It's possible that you will need something else entirely.
>>>> Possibly true.
>>>>
>>>>> You may find that a hardware reference clock; e.g. a GPS timing 
>>>>> receiver, will help.  With a GPS timing receiver, you will not be 
>>>>> dependent on the internet for time sources.  NTPD will still need 
>>>>> about thirty minutes to gain really tight synchronization.  Once 
>>>>> gained, synchronization should be stable as long as the machine is up.
>>>> Actually it is much worse than that. On my system, on bootup the clock
>>>> frequency can very by up to about 50PPM due to a Linux bug. In 
>>>> general it
>>>> takes ntp about 10 hours to regain tight synchronisation. (In that 
>>>> case it
>>>> is microsecond since it is synching to a GPS, but it is also on poll 
>>>> level
>>>> 4 so it has lots of data and should converge faster than some other 
>>>> system
>>>> on poll level 6-10). David Mills has always insisted that ntpd is 
>>>> designed
>>>> for stable long time operation, and rapidity of response is a 
>>>> distant 49th
>>>> or so in priority.
>>
>>> My Solaris 8 SPARC system seems to be able to synch with the GPS 
>>> receiver in about 30 minutes.  I may reboot that system once a year 
>>
>> IF the frequency after reboot is very close to the frequency before 
>> (<1PPM
>> say) and the clock has not drifter far out ( 1ms say) then sure. 
>> Otherwise
>> it is a disaster.

If I just do a "warm start"; e.g. init 6, with a good drift file, I 
expect to have tight synchronization very quickly; certainly not more 
than thirty minutes.

If the machine is actually powered down for a while, it may take much 
longer to achieve tight synchronization.

It's not a problem I face very often!  I have 202 days uptime at the 
moment.  If we don't have a power outrage, there's no reason for a 
reboot, we just keep ticking along!

_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions

Reply via email to