[ntp:questions] Ntp not syncing after powerfail of server
unruh at wormhole.physics.ubc.ca
Fri May 20 10:10:35 UTC 2011
On 2011-05-20, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> On 5/19/2011 12:08 PM, M. Giertzsch wrote:
>> Am 19.05.2011 17:55, schrieb Chris Albertson:
>>> On Wed, May 18, 2011 at 2:57 AM, M. Giertzsch<mgiertzsch at mobotix.com>
>>>> Now if there is a powerfail, there is no guarantee that the server has
>>>> finished the boot
>>>> before the clients have. In this case the time will not be synced.
>>> If the clients are running the standard ntpd they will continue poling
>>> "forever" and the server can go up and down. The clients can sync to
>>> it when it is up and of course can't if it isn't.
>>> BTW it helps to have more than one NTP server. How do you know you
>>> server is serving correct time without some kind of redundant check?
>> Hi Chris,
>> thank you for your reply.
>> This is of course true, I can't say that that one server serves the
>> correct time.
>> But in a closed environment I can't guarantee that even when using more
>> If real time is needed I'm in need of a GPS module or something like this.
> A GPS Timing Receiver gives you time traceable to NIST.
>> But hmm, still it seems to me that the client does not sync when
>> finished booting
> NTPD needs something like thirty minutes before it is able to serve a
> reasonable facsimile of the correct time. It needs up to ten hours
> after startup to deliver the highest quality time that it is capable of.
> The corollary to this is that you can't expect NTPD to run 9 AM to 5 PM
> and deliver the best possible quality of time. If you want the best
> possible accuracy, you run NTPD 24x7.
> There is another program whose name I forget, that does a much faster
> startup at the the price of slightly poorer quality of time.
YOur might be referring to chrony, which syncs much faster, responds to
rate changes much faster and delivers must higher qualitty of time.
>> before the server does. What about that iburst mentioned in my recent
>> post and may it be that
>> I have to be more patient waiting for the next poll (but I waited half
>> an hour).
> Something is very wrong there. NTPD adjusts its poll interval from 32
> or 64 seconds to 1024 seconds as needed. Over simplifying, the short
> poll intervals give you a relatively speedy convergence to to something
> close to the correct time. Longer poll intervals give better accuracy.
> The "IBURST" keyword causes NTPD to initially send eight requests at
> intervals of two seconds. The information thus obtained gets NTPD
> initialized more rapidly than it would be otherwise.
More information about the questions