Messages in this thread | | | Date | Mon, 7 Dec 2015 17:14:38 -0800 | Subject | Re: [RFC][PATCH] timekeeping: Cap adjustments so they don't exceede the maxadj value | From | John Stultz <> |
| |
On Mon, Dec 7, 2015 at 6:43 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote: > On Fri, Dec 04, 2015 at 01:57:54PM -0800, John Stultz wrote: >> Thus its been occasionally noted that users have seen >> confusing warnings like: >> >> Adjusting tsc more than 11% (5941981 vs 7759439) > > Thanks for looking into this, John. > >> Thus this patch adds some extra logic to enforce the max adjustment >> cap in the internal steering. >> >> Note: This has the potential to slow corrections when the ADJ_TICK >> value is furthest away from the default value. So it would be good to >> get some testing from folks using Chrony, to make sure we don't >> cause any troubles there. > > I ran few tests with chronyd, forcing it to make the largest possible > adjustment of the tick and it seems to work fine. > > However, I'm still able to trigger the warning by feeding a large > offset to the NTP PLL using a short time constant. When the multiplier > is already at the maximum and it wants to move it even further, there > should be no timekeeping_apply_adjustment() call as it always adjusts > the multiplier at least by one.
Ack. Thanks for noticing this. I could reproduce it and have a fix. Will send an update out later.
thanks -john
| |