Re: Regression: can't apply frequency offsets above 1000ppm.

[Miroslav Lichvar <mlichvar@redhat.com>]

On Wed, Sep 02, 2015 at 02:14:21AM +0100, Nuno Gonçalves wrote:
> On Wed, Sep 2, 2015 at 2:03 AM, John Stultz <john.stultz@linaro.org> wrote:
> > On Tue, Sep 1, 2015 at 5:36 PM, Nuno Gonçalves <nunojpg@gmail.com> wrote:
> >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dc491596f6394382fbc74ad331156207d619fa0a
> >>
> >> I've triple checked it this time. Not sure where I did the mistake to
> >> get it wrong by 3 commits.
> >
> > This commit is much more believable (though surprising as that change
> > was found to greatly improve results for most uses).
> >
> > Can you provide any more details about how the problem is reproduced
> > (kernel config, what userland images are you using, etc)?  I've got a
> > BBB myself so I can try to see whats going on.

> And just installing chrony from the feeds. With any kernel from 3.17
> you'll have wrong estimates at chronyc sourcestats.

Another reproducer is to disable chronyd, set the adjtimex tick to
9000 (e.g. by the adjtimex utility) and observe how is the offset of
the clock changing over time, e.g. by running periodically ntpdate -q
or chronyd -Q. It should be losing about 0.1 second per second, but
the actual frequency offset seems to be much smaller.

> Miroslav also dismissed this being related to nohz after some tests.

Yeah, the problem didn't disappear when the kernel was booted with
nohz=off, so I thought it was something else. Now that it seems it
indeed is related to nohz, I guess it's not a problem with the clock
update interval being too long (which the referenced commit
addressed).

Anyone knows what values (mask, mult, shift, maxadj) has the
clocksource in this case? I'd like to try to reproduce the problem in
the simulator.

-- 
Miroslav Lichvar