Re: [chrony-dev] Poll adjust after long time unreachable?

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Fri, 16 Aug 2013, Miroslav Lichvar wrote:

> > Also, after a long time of not reaching the source (tx_count has been
> > large) and we finally get the source again,
> > should the poll interval not be dropped back down to something like minpoll so
> > the system can resynchronize relatively quickly?
> > (or maybe this does happen somewhere I have not found).
> >
> > Ie, in lines 1137-1141 of ntp_core.c
> >    if (valid_header && valid_data) {
> >     inst->remote_poll = message->poll;
> >     inst->remote_stratum = message->stratum;
> >     inst->tx_count = 0;
> >     SRC_UpdateReachability(inst->source, 1);
> > do something like
> > if (inst->tx_count >5 ) inst->local_poll=inst->minpoll;
> > or
> > if(inst->txcount>4) adjust_poll( inst, -(double)inst->tx_count/4.);
> > (this would return it to roughly the same poll count it had before it became
> > unreachable, but maybe it should drop even more).
> > before the inst->tx_count = 0;
> > line.
>
> The current code will drop to a shorter polling interval if the error
> in the predicted offset is larger than the peer distance, see the
> get_adj_poll function. If you want to make the poll adjustment also a
> function of the number of missed polls, please add a new parameter to
> the function and make the changes there.
>
> > Ie, during the time the source was unreachable, the poll gradually increased,
> > but if it comes back after a long time unreachable, one should decrease the
> > poll interval after it comes back to recover quickly from the missing return
> > packets. One could get the case where one was on
> > minpoll when the remote source became unreachable, it gradually increased to
> > maxpoll while it is unreachable, and then when it comes back, it is stuck on
> > maxpoll, meaning the system time is left wrong for even longer than necessary.
>
> One reason for a larger number of missed polls might be overloaded
> server. If all clients dropped to minpoll immediately, it would only
> make it worse. I'd suggest to focus on improving the adjustment from
> the error in the prediction instead of hardcoding a drop to minpoll.

Hmm. valid point. But I suspect that the more usual case is that the internet
connection goes down for a while. This means that it takes a long time for the
system to respond when the internet comes up again especially as it has
climbed in poll interval while the network was down. And I am not suggesting
that they drop to minpoll immediately (tx_count >5 so that means 4 missed
return packets). Thus at poll 10, it takes 20 min for the system to finally
get another packet, and then it will take a few of those for the system to
finally drop down in the poll interval. Ie, it could take a long time to
recover from a dropped network. One of the nice features of chrony is the
rapidity of its response, and this works against that.


By the way, have you ever thought about making chrony use say a quadratic
predictor, rather than just a linear? Not sure if that would make the
prediciton better or worse in some cases however. In general for slow drifts
in the rate it should make it better. But sometimes on severe changes, it
could make things worse.





>

--
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

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