From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754618AbbICL3s (ORCPT <rfc822;w@1wt.eu>);
	Thu, 3 Sep 2015 07:29:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:55234 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751225AbbICL2m (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Sep 2015 07:28:42 -0400
Date: Thu, 3 Sep 2015 13:26:47 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: John Stultz <john.stultz@linaro.org>
Cc: Nuno =?iso-8859-1?Q?Gon=E7alves?= <nunojpg@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        =?iso-8859-1?Q?G=FCnter_K=F6llner?= <dl4mea@yahoo.de>,
        stable <stable@vger.kernel.org>
Subject: Re: Regression: can't apply frequency offsets above 1000ppm.
Message-ID: <20150903112647.GD29274@localhost>
References: <CAEXMXLRPvKqGvzTiqb8mKNXOS+beaB2AJCdb=ZCwHwn1Nyk-yQ@mail.gmail.com>
 <alpine.DEB.2.11.1509012207140.15006@nanos>
 <CAEXMXLRGjicdeMExFrCR+EnNcfFwJS2Y-EcXC-h9wEbm1hFEaQ@mail.gmail.com>
 <CALAqxLUyMAYj9RBArmkp7kkz6NkfT-mrvh7gBw++ZZZ1tFY37w@mail.gmail.com>
 <CAEXMXLRa+OBG+XxWDzt5YOxi=EoGomB0C0ppJNmGfFpdLmXgmw@mail.gmail.com>
 <CALAqxLXPkf1KAO=qt92LT2mOo4FqhcOrvC0P9Sq8QxQ14Y+ueA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALAqxLXPkf1KAO=qt92LT2mOo4FqhcOrvC0P9Sq8QxQ14Y+ueA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Wed, Sep 02, 2015 at 04:16:00PM -0700, John Stultz wrote:
> On Tue, Sep 1, 2015 at 6:14 PM, Nuno Gonçalves <nunojpg@gmail.com> wrote:
> > And just installing chrony from the feeds. With any kernel from 3.17
> > you'll have wrong estimates at chronyc sourcestats.
> 
> Wrong estimates? Could you be more specific about what the failure
> you're seeing is here? The
> 
> I installed the image above, which comes with a 4.1.6 kernel, and
> chrony seems to have gotten my BBB into ~1ms sync w/ servers over the
> internet fairly quickly (at least according to chronyc tracking).

To see the bug with chronyd the initial offset shouldn't be very close
to zero, so it's forced to correct the offset by adjusting the
frequency in a larger step.

I'm attaching a simple C program that prints the frequency offset
as measured between the REALTIME and MONOTONIC_RAW clocks when the
adjtimex tick is set to 9000. It should show values close to -100000
ppm and I suspect on the BBB it will be much smaller.

-- 
Miroslav Lichvar

--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="rawfreqoff.c"

#include <stdio.h>
#include <sys/timex.h>
#include <time.h>
#include <unistd.h>

#define DIFFTS(a, b) ((a.tv_sec - b.tv_sec) + 1e-9 * (a.tv_nsec - b.tv_nsec))

int main() {
	struct timespec ts1, ts2, ts3, ts4 = {0};
	struct timex t;

	t.modes = ADJ_TICK;
	t.tick = 9000;
	if (adjtimex(&t) < 0)
		return 1;

	while (1) {
		clock_gettime(CLOCK_REALTIME, &ts1);
		clock_gettime(CLOCK_MONOTONIC_RAW, &ts2);

		if (ts4.tv_sec)
			printf("freq offset = %.0f ppm\n",
				(DIFFTS(ts1, ts3) / DIFFTS(ts2, ts4) - 1.0) * 1e6);

		ts3 = ts1;
		ts4 = ts2;
		usleep(1000000);
	}

	return 0;
}

--HlL+5n6rz5pIUxbD--