[ntp:questions] Meinberg NTP monitor, silly question

Richard B. Gilbert rgilbert88 at comcast.net
Tue Dec 22 21:00:36 UTC 2009


unruh wrote:
> On 2009-12-22, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>> unruh wrote:
>>> On 2009-12-22, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>>>> David J Taylor wrote:
>>>>> "G8KBV" <g8kbv at nospam-uko2.co.uk> wrote in message 
>>>>> news:MPG.2599f4f8b90958d1989692 at news.demon.co.uk...
>>>>> []
>>>>>
>>>>> You will find that for the best performance, the NTP PC needs to be left 
>>>>> running, as initial settling is not quick.
>>>>>
>>>> "Not quick" is an extreme understatement!  It takes about 30 minutes to 
>>>> get a "reasonable approximation".  It can take ten to twelve hours to 
>>>> stabilize with the best possible approximation of the time.  Once there 
>>>> it's good for as long as you can keep the power on and the temperature 
>>>> reasonably stable.
>>> Yes, the time scale is about 1 hour half life (it takes about 1 hour to
>>> halve the error). David Mills gets really
>>> annoyed if someone points out how slow ntp is at converging. It is
>>> definitely a feature, not a bug. That you or I could, with the first
>>> three offset measurements, make a far better approximation to the true
>>> time and rate than ntp does, is irrelevant. 
>> Well, you could always try to create an NTPD that would converge more 
>> quickly without introducing some other nastiness.  Somehow I think this 
>> would be a massive project and is quite likely impossible.  If Dave 
>> Mills thinks it won't work he's probably right.
> 
> As I said, it has already been done. It is called chrony. And it works--
> about three times better accuracy than ntpd in the tests I ran, and far
> far faster convergence. It impliments an almost complete ntpd 3.0
> standard,(without broadcast option, but as of 1.24-pre1 with refclock
> support). It does not work on Windows machines. 
> 
> David decided on a simply Markovian feedback loop with one single
> "memory"-- the current rate. It is simple, easy to analyse ( although
> with the additional bells and whistles like the clock filter, the huff
> and puff filter, stepping,  etc, it is far more difficult to analyse),
>  and has been tested extensively. That does not mean it is the best
>  way of using the data, and certainly as far as rate of convergence
>  is concerned it is far from the best. 
> 
> 
> 
>> Keeping an NTPD server up and synched is not all that difficult.  A UPS 
>> will keep you alive for three to fifteen minutes if power fails.  The 
>> longer the UPS run time, the more it costs.  Any longer than fifteen 
>> minutes and you will need a generator fueled by either gasoline or 
>> natural gas.  You will either need a human being to start it and set it 
>> for the right speed or a device that will do this automagically.
> 
> Lets see, Pay a few $100 for a UPS (and many more for a generator) ,
>  run the machine 24/7 with the associated energy costs, or load a free 
> program. Hmm.
> 

Most computers that need accurate time live in a data center somewhere 
and shut down maybe as often as once every six months!  I've had a few 
machines that ran continuously for a year or more!  It's not impossible; 
it just requires a lot of luck OR heavy expenditures for a UPS, a backup 
generator, N+1 redundant air conditioners, etc, etc.  Some enterprises 
require this sort of uptime and are prepared to pay the bills.




More information about the questions mailing list