Brian, The 500 PPM limit in the reference implementation was originally set to match the adjtime() slew of that value, but so many kernels have been hacked adjtime that this might not even be appropriate now. The bottom line is that an update given to adjtime() should be completed before the next update. Even if it's not, the leftover is carried over to the next update. However, in order to avoid disturbing application programs that compute intervals, the slew rate should be no more than necessary.
Dave Brian Utterback wrote: > Danny, I agree with everything you said except: > > Danny Mayer wrote: > >>> >> >> I agree. I don't see how it can be a specification violation. The >> biggest factor is how well it keeps time. A caesium clock keeps good >> time but you wouldn't say that it violates the specification. >> > > When we first started looking at the V4 spec for the ntp-wg, my first > thought was the same as yours, namely that what happens inside a system > shouldn't matter, the algorithms don't matter, only what it chimes > matters. And strictly speaking, this is true. However, after reading > Dave's book (Das Buch as he calls it), I realized that an important > factor to the stability of the NTP network is the actual speed at > which the clocks slew, i.e. the 500 PPM limit. This is largely > ignored in the spec. I sent in some comments about how I thought it > should be addressed but alas, my changes didn't make it in the latest > versions. > > Brian Utterback _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
