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@xxxxxxxxxx> wrote: > > On Tue, Sep 1, 2015 at 5:36 PM, Nuno Gonçalves <nunojpg@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html