From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: [PATCH for-next V2 0/9] Add completion timestamping support Date: Sat, 6 Jun 2015 23:25:25 +0300 Message-ID: References: <1433074457-26437-1-git-send-email-ogerlitz@mellanox.com> <1433098827.114391.179.camel@redhat.com> <1433157904.114391.188.camel@redhat.com> <20150601164322.GA14391@obsidianresearch.com> <1433255724.114391.225.camel@redhat.com> <20150602180844.GD17776@obsidianresearch.com> <20150603204633.GE7902@obsidianresearch.com> <20150604042540.GA8837@obsidianresearch.com> <1433605546.40123.217.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1433605546.40123.217.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Doug Ledford Cc: Christoph Lameter , Jason Gunthorpe , Matan Barak , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Amir Vadai , Tal Alon List-Id: linux-rdma@vger.kernel.org On Sat, Jun 6, 2015 at 6:45 PM, Doug Ledford wrote: >>> So no, I disagree that rough is fine for anything. >> I am sorry but the practical issues that we are dealing with in >> timekeeping today shows just the opposite. For a true comparison of clocks >> with nanosecond accuracy you would need time corrected values and that is >> a challenge due to the variances of the clocks that we see. > Jason's point, and one that isn't addressed yet, is that this might not > be variance in the clocks and instead might be a design flaw in the API > you are using and the way the clock speeds are passed to user space. > Changing from int MHz to int KHz might solve your problem. OK, so if we have the UAPI to pass the clock frequency in KHz that would put us in a better place? seems very much doable. Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html