[ntp:questions] NTP offset doesn't change.

William Unruh unruh at invalid.ca
Sun Feb 15 19:46:23 UTC 2015


On 2015-02-15, Philip Homburg <philip at ue.aioy.eu> wrote:
> In article <mbqnu5$f15$3 at dont-email.me>,
> William Unruh  <unruh at invalid.ca> wrote:
>>I bring up chrony not to discuss it as a program but todiscuss its
>>philosophy of clock control and its design. It presents an alternative
>>to the approach of ntpd, which ntimed appears to be following. 
>
> There is plenty of documentation on how NTP was designed. PHK has 
> a series of articles on the approach he has taken in ntimed, but I can't
> find anything similar for chrony. Do you have a pointer to the design docs
> of chrony?

The documentation has some, but much is in the code. 

The basic idea is that the usual ntp packets are used to get time from a
remote system. chrony places each offset into an array for each source--
up to 64 entries long if I remember correctly. A linear regression is
performed on those entries. That linear regression is tested for
linearity by looking at the number of times that the residual changes
sign. If the number of times is too small, it means that the residuals
tend to cluster on one side or the other too much and a linear model is
a bad model, so the number of offsets saved is reduced either until the
linear fit passes the test, or there are only 3 entries left. That
linear regression is then used to determine the current offset of the
clock and the drift rate. The drift rate is changed (using adjtimex) and
all of the offsets in the array are adjusted to take into account the
new drift rate and the new offset after adjustment. 

The offsets coming in are tested with all of the usual ntp tests, but
also the delays are tested if you have that switched on, to see if the
delay is much longer than the minimum remembered delay (amount
adjustable) 



>
>



More information about the questions mailing list