From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752581AbbIBHjZ (ORCPT ); Wed, 2 Sep 2015 03:39:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37915 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750806AbbIBHjX (ORCPT ); Wed, 2 Sep 2015 03:39:23 -0400 Date: Wed, 2 Sep 2015 09:39:21 +0200 From: Miroslav Lichvar To: Nuno =?iso-8859-1?Q?Gon=E7alves?= Cc: John Stultz , Thomas Gleixner , LKML , dl4mea@yahoo.de, stable Subject: Re: Regression: can't apply frequency offsets above 1000ppm. Message-ID: <20150902073921.GD22140@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: > > On Tue, Sep 1, 2015 at 5:36 PM, Nuno Gonçalves 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