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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Sep 2015 09:39:21 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	Nuno Gonçalves <nunojpg@...il.com>
Cc:	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>, dl4mea@...oo.de,
	stable <stable@...r.kernel.org>
Subject: Re: Regression: can't apply frequency offsets above 1000ppm.

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@...aro.org> wrote:
> > On Tue, Sep 1, 2015 at 5:36 PM, Nuno Gonçalves <nunojpg@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/