From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFE58C0044C for ; Thu, 1 Nov 2018 18:04:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 79C372064C for ; Thu, 1 Nov 2018 18:04:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79C372064C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727989AbeKBDH7 (ORCPT ); Thu, 1 Nov 2018 23:07:59 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:57917 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727417AbeKBDH7 (ORCPT ); Thu, 1 Nov 2018 23:07:59 -0400 Received: from p5492fe24.dip0.t-ipconnect.de ([84.146.254.36] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gIHJh-00088J-Sg; Thu, 01 Nov 2018 19:03:38 +0100 Date: Thu, 1 Nov 2018 19:03:37 +0100 (CET) From: Thomas Gleixner To: John Stultz cc: Christopher Hall , "H. Peter Anvin" , linux-rt-users , jesus.sanchez-palencia@intel.com, Gavin Hindman , liam.r.girdwood@intel.com, Peter Zijlstra , LKML , Miroslav Lichvar Subject: Re: TSC to Mono-raw Drift In-Reply-To: Message-ID: References: <20181015160945.5993-1-christopher.s.hall@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 1 Nov 2018, John Stultz wrote: > On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner wrote: > > On Tue, 23 Oct 2018, John Stultz wrote: > >> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote: > >> I spent a little bit of time thinking this out. Unfortunately I don't > >> think its a simple matter of calculating the granularity error on the > >> raw clock and adding it in each interval. The other trouble spot is > >> that the adjusted clocks (monotonic/realtime) are adjusted off of that > >> raw clock. So they would need to have that error added as well, > >> otherwise the raw and a otherwise non-adjusted monotonic clock would > >> drift. > >> > >> However, to be correct, the ntp adjustments made would have to be made > >> to both the base interval + error, which mucks the math up a fair bit. > > > > Hmm, confused as usual. Why would you need to do anything like that? > > Because the NTP adjustment is done off of what is now the raw clock. > If the raw clock is "corrected" the ppb adjustment has to be done off > of that corrected rate. Sure, but why would that require any change? Right now the raw clock is slightly off and you correct clock monotonic against NTP. So with that extra correction you just see a slightly different raw clock slew and work from there. > Otherwise with no correction, the raw clock and the monotonic clock > would drift apart. They drift apart today already if you do NTP correction. They stay in sync w/o NTP/PTP/PPS. But maybe I confused myself completely by now. Thanks, tglx