| Re: [chrony-dev] Poll adjust after long time unreachable? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Fri, Aug 16, 2013 at 07:44:06AM -0700, Bill Unruh wrote:
> I was just looking at adjust_poll in ntp_core.c and am confused by some of the
> lines there.
> } else if (inst->local_poll > inst->maxpoll) {
> inst->local_poll = inst->maxpoll;
> inst->poll_score = 1.0;
> }
> So if local_poll is larger that maxpoll, it is clamped to maxpoll, but
> poll_score is made equal to 1 which means on the next round, it will again be
> increment local_poll and go through this round again. Ie, why in this
> situation is poll_score set to 1 rather than 0?
It's set to 1.0 to avoid dropping to maxpoll - 1 too easily. It should
react as if the local poll was maxpoll + 1.
> 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.
--
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.