| Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.26-26-g9a01ccc |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Tue, Nov 15, 2011 at 10:28:31AM -0800, Bill Unruh wrote:
>
> I am a bit confused both about the reason for and the details of this
> alteration. chrony determines both the offset error and the frequency error.
The main reason is that adjtime() slews at a fixed rate of 500 ppm.
On the graphs of frequency error there are huge spikes. If an
application is measuring a short interval just when the adjustment is
running, it will get 500ppm error.
> It corrects the frequency error immediately, and then adjusts the frequency to
> eliminate the offset error.
With the old code only larger (>0.2s) errors were corrected by changing
kernel frequency. Normally adjtime() was called or the PLL phase
adjustment was made (<10us) as adjtime has only microsecond
resolution.
The new code uses the frequency change for errors above 0.5 second and
the PLL for everything else (if it's available).
It certainly is possible to use the frequency change for all offset
corrections, but I think the need for scheduling a timeout to cancel
the frequency change is a big disadvantage for it to be the primary
offset adjustment method. It's not accurate as it's not known when
exactly it was started and ended, so a dispersion needs to be added to
all past samples on every adjustment, it can run out if the machine or
the process is suspended and it introduces extra process wakeups.
> I am not sure what the reason is behind the
> "eliminate small errors over a long time, and large errors quickly". This
> looks like it is heading for the step type adjustment of ntpd for larger
> offset errors.
The maximum rate is limited by the allowed range for the PLL time
constant, with the minimum time constant (4s) and the maximum offset
(0.5s) it is 12.5% in the first second.
> Is your thinking that small errors are probably not true
> offsets but noise and thus should not really be corrected?
Yes. If the offset stddev is 1 ms and we want to correct 500 us, there
is no point in slewing that in one second. OTOH, 10ms offset is
significant and should be removed quickly.
> What are the
> consequences of this change to the stability of the system?
I think it should be ok, simulations and the previous use of the PLL
for nanosecond corrections seemed fine.
--
Miroslav Lichvar
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.