[ntp:questions] Meinberg NTP monitor, silly question

Richard B. Gilbert rgilbert88 at comcast.net
Tue Dec 22 20:47:35 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.
> 

And chrony will start up and give time to the microsecond and not drift 
as it warms up?  There must be SOME reason why we are not all running 
chrony!




More information about the questions mailing list