From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 17:31:15 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 61DFB10656EF for ; Thu, 9 Jul 2009 17:31:15 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A829D8FC24 for ; Thu, 9 Jul 2009 17:31:14 +0000 (UTC) (envelope-from avg@freebsd.org) 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 UAA15356 for ; Thu, 09 Jul 2009 20:31:13 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A562960.3010801@freebsd.org> Date: Thu, 09 Jul 2009 20:31:12 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: dtrace users opinion solicited (timestamps) 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: Thu, 09 Jul 2009 17:31:16 -0000 As you might be aware DTrace timestamps right now are derived from TSC value. http://en.wikipedia.org/wiki/Time_Stamp_Counter DTrace timestamps are measured in nano-seconds and the formula similar to the following is used for calculations: rdtsc() * 1000000000 / tsc_freq where rdtsc is a function that returns current TSC value and tsc_freq is a frequency of TSC. This formula is supposed to produce proper results if tsc_freq stays constant. But there are environment where this might not be the case. If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. because of powerd), then tsc_freq changes too. As a result, the formula would produce wildly different values and, most importantly, was values would non be monotonic. Timestamp values that jump back and forth would not only be useless for a user, they would also confuse DTrace internal logic. There are at least the following two alternatives: 1. Keep things as they are and warn users not to change CPU clock frequency when they use DTrace and the CPU doesn't have invariant TSC. I think that this should cause only minor inconveniences to a portion of DTrace users. 2. Use raw TSC value as a DTrace timestamp and document this difference from the original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: manual conversion is needed to get "real" time (using the same formula). Please note that in this case timestamps would be in non-linear time dimension if TSC frequency changes, so to get meaningful timestamps (when needed/important) one would still have to make sure that TSC frequency stay constant. Please share your opinion on these approaches. Or suggest yest another alternative. Just in case, related sysctls: machdep.tsc_freq kern.timecounter.invariant_tsc -- Andriy Gapon