Re: [chrony-dev] handling of unstable sources

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Jul 06, 2010 at 02:55:16PM +0200, Frank Muzzulini wrote:
> I configured two servers, both stratum 1, configured with minpoll 5
> maxpoll 8:
> A was modern one, internally running ntpd on an embedded linux. Its
> measurements were very stable.
> B was an old hardware solution. It provided time only with
> ms-resolution (thus measurements seem to deviate by +-500us) and in
> the long run it produces a saw-tooth effect (slightly drifting off,
> then jump 5ms to correct it, etc). Being a primary source without
> any complex logic it always reports its root dispersion as 0.
> 
> Now I observed the following behaviour:
> 
> 1.
> A steadily increased to poll 8
> B always stuck to poll 5 or 6
> 
> Not really a problem, although I think that in the long run such
> "random" deviations might be better handled with long polling rates.

Yes, I've seen this with some unstable pool.ntp.org servers. The
current code assumes that when we have problems tracking the source,
it's the local clock causing it and the polling rate is increased.

Maybe if each source had a long-term skew statistic, with multiple
sources we could compare it to the minimum of all sources and use
that to determine if it's the local clock or the server which is
unstable. Not sure how well this would work.

> 2.
> Chronyd switched between "no majority" and selecting one of the
> servers almost every other minute, reporting local stratum in the
> "no majority" phases.

That means that the intervals offset +- distance for the sources
didn't overlap, both were marked as falsetickers and when they
overlapped again, the source which had a smaller distance at the
moment was selected as system peer.

Adding a third source might help. Generally, running with two sources
is the hardest configuration for chrony to handle well.

Of cource, this doesn't mean it can't be improved :). Ideally, chrony
should be able to compare the frequency statistics of all sources,
possibly do some clustering on frequency offsets, and mark the
unstable sources as falsetickers.

> Considering the fact that without any meassurements it sticks to a
> server (and the related stratum) much longer, I wonder why it does
> not stick to one of the servers in that case.
> 
> 3.
> In the long run chronyd seemed to prefer server B.
> 
> Now this is really odd. Is this caused by the claimed low root
> dispersion or because it got more meassurements from it? What ever
> the reason is, it would be better to prefer the stable server.

Interesting. Maybe the 1ms resolution is causing chrony to think it's
following the source very well for short intervals. The statistics and
measurements logs would help.

-- 
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.