Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751647AbbG1EF3 (ORCPT ); Tue, 28 Jul 2015 00:05:29 -0400 Received: from mail-ig0-f180.google.com ([209.85.213.180]:37792 "EHLO mail-ig0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805AbbG1EF2 (ORCPT ); Tue, 28 Jul 2015 00:05:28 -0400 MIME-Version: 1.0 In-Reply-To: References: <1438044416-15588-1-git-send-email-christopher.s.hall@intel.com> <1438044416-15588-2-git-send-email-christopher.s.hall@intel.com> Date: Mon, 27 Jul 2015 21:05:27 -0700 Message-ID: Subject: Re: [PATCH 1/5] Add functions producing system time given a backing counter value From: John Stultz To: Christopher Hall Cc: Thomas Gleixner , Richard Cochran , Ingo Molnar , Jeff Kirsher , john.ronciak@intel.com, "H. Peter Anvin" , "x86@kernel.org" , lkml , netdev@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2006 Lines: 50 On Mon, Jul 27, 2015 at 8:44 PM, John Stultz wrote: > On Mon, Jul 27, 2015 at 5:46 PM, Christopher Hall > wrote: >> * counter_to_rawmono64 >> * counter_to_mono64 >> * counter_to_realtime64 >> >> Enables drivers to translate a captured system clock counter to system >> time. This is useful for network and audio devices that capture timestamps >> in terms of both the system clock and device clock. > > Huh. So for counter_to_realtime64 & mono64, this seems to ignore the > fact that the multiplier is constantly adjusted and corrected. So that > calling the function twice with the same counter value may result in > different returned values. > > I've not yet groked the whole patchset, but it seems like there needs > to be some mechanism that ensures the counter value is captured and > used in the same (or at least close) interval that the timekeeper data > is valid for. So reading through. It looks like you only use art_to_realtime(), right? So again, since CLOCK_MONOTONIC and CLOCK_REALTIME are constaly being frequency adjusted, it might be best to construct this delta in the following way. Add counter_to_rawmono64(), which should be able to safely calculate the corresponding CLOCK_MONOTONIC_RAW time from any given cycle value. Use getnstime_raw_and_real() to get a immediate snapshot of current MONOTONIC_RAW and REALTIME clocks. Then calculate the delta between the snapshotted counter raw time, and the current raw time. Then apply that offset to the current realtime. The larger the raw-time delta, the larger the possible realtime error. But I think that will be as good as it gets. This should simplify the interfaces you're adding to the timekeeping core. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/