[ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

unruh unruh at wormhole.physics.ubc.ca
Sat Mar 12 07:49:39 UTC 2011

On 2011-03-12, Ralph <ralph at depth.net> wrote:
> @Chris
> I appreciate the offer to help.
> I've been thinking about this problem a while and here are my thoughts... It 
> seems to me that ntpd has the goal of keeping extremely accurate time - which
>  is important for many obvious reasons.  However there are those of us that
> don't need time accurate to the millisecond and / or don't need time to be 
> perfectly in sync with the rest of the world.
> With that in mind, it would be nice if there was something out there that 
> operated in a slightly different mode than ntpd does... It appears that the 
> problem that ntpd has is that because the distance between ticks on the local 
> machine are variable and therefore calculating the time between a transmission 
> and receipt is 'impossible'.  But why not have something that assumes that 

No, that is not the problem. The problem is that the computer has an
internal clock that depends on things like counting processor cycles. If
suddenly the processor disappears for a while with no processor cycles,
the timing will be messed up. ntpd cannot do anything about that. It
just looks as if the local call has suddenly slews backwards. 

> the local ticks simply can't be trusted?  Keep track of how far off the local 
> clock is from the ntp sources (averaged over numerous queries) and adjust the 


> clock based on the average adjustment that is needed.  Don't mess with trying 

That is what ntpd does. It does it by adjusting the rate of the clock.

> to calculate the time taken for the round trip and all that, if the replies

And how does it know what the ntp sources say the time is then?

> back from servers are within a certain amount of time of one another, then just
> average them out.  
> If you do something similar to what I suggest, you will end up running further 'behind' than a ntpd server that has consistent ticks, but you ought to
> at least be able to have something that disciplines the clock into running 
> fairly close to real time on average and stays within a handful of seconds 
> within 'real' time.

Nope. ntpd adjusts a clock by altering the rate of the clock. But it has
a hard 500PPM limit on the rate, and such a rate adjustment will bring
the rate to a place which is trying to adjust for a bunch of lost ticks.
This is made particularly bad because ntpd has a horrible adjustment
time to a change in rate ( hours). It is NOT designed to compensate for
such variable rates. 

On linux, chrony might be better ( it has no 500PPM limit, more like
100000PPM) and has a much much faster response to rate changes. But even
it will have a hard time keeping up with a clock which randomly looses
chuncks of time.  Alternatively, you could run ntpdate everyminute and
just jump the clock to the right time. It will tick by fits and starts,
but the time may be not too badly out. 

> As I said, this probably is a completely different solution than ntpd, but it 
> seems like it would be really useful for people that are more concerned with 
> making time consistent / realistic than they are with making it ultra-accurate. 
> And this could also be very useful for people that have hardware clocks that 
> don't seem to run consistently enough for ntpd - the people whom I've seen been 
> told to replace their motherboard in order to get a clock that can keep time.
> I'm no time expert, so feel free to explain where I've lost my mind if I'm not 
> thinking through this all the way...

More information about the questions mailing list