From owner-freebsd-current@FreeBSD.ORG Mon Jun 22 11:07:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 855D01065675; Mon, 22 Jun 2009 11:07:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 015B88FC08; Mon, 22 Jun 2009 11:07:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA08873; Mon, 22 Jun 2009 14:07:43 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A3F65FF.7050200@icyb.net.ua> Date: Mon, 22 Jun 2009 14:07:43 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Thomas Backman References: <668B820A-AAA7-4A40-8CF5-7DDCFDCD95FC@exscape.org> In-Reply-To: <668B820A-AAA7-4A40-8CF5-7DDCFDCD95FC@exscape.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Birrell , FreeBSD current Subject: Re: DTrace "timestamp" wraps at about 2^33 (64-bit value)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 11:07:50 -0000 on 20/06/2009 19:29 Thomas Backman said the following: > It appears the DTrace "timestamp" variable is wrapping around way, way > too quickly - it only goes to somewhere slightly above 2^33 (in > practice, at least), and since it's in nanoseconds, that's not a lot. > (2^33 ns is less than 10 seconds, actually. 2^64 is 584.55 years, however!) [snip] > uint64_t > dtrace_gethrtime() > { > return ((rdtsc() + tsc_skew[curcpu]) * (int64_t) 1000000000 / tsc_freq); It appears that (rdtsc() + X) * 10^9 overflows 64-bit value for sufficiently small values of rdtsc. BTW, I think it would have been better/clearer to use uint64_t in the cast. I think that to minimize overflow and sufficiently accurate result a formula like the following could be used: x = rdtsc() + tsc_skew[curcpu]; sec = x / tsc_freq; r = x % tsc_freq; res = sec * 10^9 + (r * 10^9 / tsc_freq); I have not tested the formula. I have suspicions about its accuracy in the edge cases, esp. if tsc_freq > (2^64 - 1) / 10^9 (not sure if have that in reality). -- Andriy Gapon