Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3702407imm; Fri, 19 Oct 2018 15:39:35 -0700 (PDT) X-Google-Smtp-Source: ACcGV60cCSGD4kXVgvMGbie2oDW7yA3rZVdhcwbfMwyGYqMm/8KoDlhw6Xv1kz1KfjpAMYRdEotd X-Received: by 2002:a63:455e:: with SMTP id u30-v6mr34332557pgk.30.1539988775142; Fri, 19 Oct 2018 15:39:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539988775; cv=none; d=google.com; s=arc-20160816; b=Lrlb8AsKa8qFglNHEOPcbWkiVA/wNi1D5v5MYA5FjfARKm9NNN3VDAnoD+2sqg/HWj lJysH47w4n9CWRiT6jGkjBvkOBDnU+MBAErn/uOHrZcuOoN2IX30LPZvtm49YOwXLdPX BPos1UkYK08vUJXH1xc8CKB94WVmCPbpFWHgTJ10CtVDQZNvt+u+UWKBEcZ0Mly57wA+ Hlu50WJ4V2frBDRB4yXPzvkDh4B2eieoDtSeWHHB6Zg4m+s47LovKGdcB7/bWJMdVaBt p7kkqVLsQkKoKiq9nfeOW7fGo6KfptpaWh4+bPON3sW3VEZEKj6tAYm7N/sNag7TyBg1 xnXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=K7FiFtkyRhJGLuJR8REjVXglC4XBDl4UOpI8qpL51HM=; b=g8GOQM1/deLEZGsgXuP/kFJi1MRx/GcVahkdpyMqVYipjLxVe/wDxLebJFaxuXHYkx hnaRa12eQfTlON8IbDoeelxH9sXl1EPOZuc6LrQETE3tw9HFdDoB/4+lvAabIqdYUnCa NGFJXRaR6tuetJmm13uSNJodOKEoy8ArR7JlixsS6hPYhs11Y3NwLTrBc75aE6e38zyA uWNLzSGWfd+d9Ibig19j3shzt44fn+IPEHxvcJ+z3DYF1OVjdZD0PQjxbOKyRZfv8arG 6PtR5+S4JiJ7MEf/wtn2suOb2PHcvr72w42GLTuiVbEP2RlAEOOVBVG+8AB7YlRou3Fq 5xYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=iVDmZrEw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b34-v6si25045081plc.428.2018.10.19.15.39.19; Fri, 19 Oct 2018 15:39:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=iVDmZrEw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727020AbeJTGo7 (ORCPT + 99 others); Sat, 20 Oct 2018 02:44:59 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:38423 "EHLO mail-wm1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726194AbeJTGo7 (ORCPT ); Sat, 20 Oct 2018 02:44:59 -0400 Received: by mail-wm1-f44.google.com with SMTP id 193-v6so5012354wme.3 for ; Fri, 19 Oct 2018 15:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K7FiFtkyRhJGLuJR8REjVXglC4XBDl4UOpI8qpL51HM=; b=iVDmZrEw70975ohezDcgsH3nj4OysHrxW85rAx7g+qHJ5XkjpY7nEbBUAeoiYYYQzB Plt7gfTk9RDgUA36DpT50SI96MAUV1aPsKQb7Cur6hPqfeYpjk6MaOQe8pQ5QLJBl+cT KnBG8J5ULn9Hjww/zDmtjE1k1cX6nmlw0gt30= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K7FiFtkyRhJGLuJR8REjVXglC4XBDl4UOpI8qpL51HM=; b=i+c2/sLVqcJiTohdZTrtAeGhdv4o5xk43AwLOyMVRzbnCE0NFMTNHSQnC8mqRbPQaw uLA88i3jk9njZBybL8QVylCs9ZjfB4UnEjQUbaYAEj0ZmZE7L4W4WDZctPT/ph7IxVP6 nHrm6QU7UwjdOFDiZEVPKbHXo/lWBxnOPLYJt2b4zPu5tmQUD4+FqkwphsyCY2Bc5BIV YsmSWLWOeM6xREXmx2FkXtML2mvSBCL5zpV+WwIHXgGhoJ+f4/XIZ9MEAo/GT7IdPiVu LoU4PTGYNJ2c3Arh1lmOcrz0RyRjWfw9H0YZqDbBr0jPgm5+17MGN+XNgSBVGmIvIn2G vDbg== X-Gm-Message-State: ABuFfohDqNpH/ugT8JLlVOoIiD1j4CWuAhcMuUVD7QFkZOgYyYgcOMMP G1k6sW5C693QwFuvJmTwQZlMX9HqzJzrzlOvQB1tk9RG X-Received: by 2002:a1c:38c5:: with SMTP id f188-v6mr6426945wma.19.1539988616516; Fri, 19 Oct 2018 15:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:b485:0:0:0:0:0 with HTTP; Fri, 19 Oct 2018 15:36:55 -0700 (PDT) In-Reply-To: References: <20181015160945.5993-1-christopher.s.hall@intel.com> From: John Stultz Date: Fri, 19 Oct 2018 15:36:55 -0700 Message-ID: Subject: Re: TSC to Mono-raw Drift To: Thomas Gleixner Cc: Christopher Hall , "H. Peter Anvin" , linux-rt-users , jesus.sanchez-palencia@intel.com, gavin.hindman@intel.com, liam.r.girdwood@intel.com, Peter Zijlstra , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote: > John, > > On Fri, 19 Oct 2018, John Stultz wrote: >> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner wrote: >> > I don't think you need complex oscillation for that. The error is constant >> > and small enough that it is a fractional nanoseconds thing with an interval >> > <= 1s. So you can just add that in a regular interval. Due to it being >> > small you can't observe time jumping I think. >> >> Well, from the examples the trouble is we seem to be a bit fast, >> rather then slow. >> So we'll have to reduce mult by one, and rework the calculations, but >> maybe something like this (correcting the raw_interval value) would >> work. > > Shouldn't be rocket science. It's a one off calculation of adjustment value > and maybe the period at which the correction happens. > >> But this also sort of breaks, fundamental argument that the raw clock >> is a simple mult/shift transformation of the underlying clocksource >> counter. Its not the accuracy of the clock but the consistency that >> was key. >> >> The counter argument is that the raw clock is abstracting the >> underlying hardware so folks who would have used the TSC directly can >> now use the raw clock and have a generic abstracted hardware-counter >> interface. So userland shouldn't really be worried about the >> occasional injections made since they shouldn't be trying to >> re-generate the abstraction from the hardware themselves. <-- >> Remember this point as we move to the next comment:) >> >> > The end-result is 'correct' as much correct it is in relation to real >> > nanoseconds. :) >> > >> >> I guess I'd want to understand more of the use here and the need to >> >> tie the raw clock back to the hardware counter it abstracts. >> > >> > The problem there is ART which is distributed to PCIe devices and ART time >> > stamps are exposed in various ways. ART has a fixed ratio vs. TSC so there >> > is a reasonable expectation that MONOTONIC_RAW is accurate. >> >> Which is maybe sort of my issue here. The raw clock provided a >> abstraction away from the hardware for generic usage, but then its >> being re-used with other un-abstracted hardware references. So unless >> they use the same method of transformation, there will be problems (of >> varying degree). > > OTOH. If people use the CPUID provided frequency information and the TSC > from userspace then they get different results which is contrary to the > goal of providing them an abstracted way of doing it. But that's my point. If they are pulling time values from the hardware directly that's unabstracted. I'm not sure its smart to be comparing the abstracted and unabstracted time stamps if your worried about precision. They are sort of two separate (though similar) time domains. >> We might be able to reduce the degree in this case, but I worry the >> extra complexity may only cause problems for others. > > Is it really that complex to add a fixed correction value periodically? > > I don't think so and it should just work for any clocksource which is > exposed this way. Famous last words ..... I'm not saying that the code is overly complex (at least compared to the rest of the timekeeping code :), but just how the accumulation is done is less-trivial. So if someone else is trying to mimic the abstracted time with unabstracted hardware values (again, not something I reccomend, but that's sort of the usage case pushing this), they need to use a similar method that is slightly more complicated (or use slower math). Its all subtle stuff, but this makes something that was relatively very simple (by design) a bit harder to explain. So I'm not out right objecting, I'm more wringing my hands at the potential edge cases that improving the accuracy of the un-adjusted clock raises. :) thanks -john