Date: Fri, 10 Jul 2009 12:12:37 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) Message-ID: <alpine.BSF.2.00.0907101211480.10745@fledge.watson.org> In-Reply-To: <4A56D87B.6000202@freebsd.org> References: <4A562960.3010801@freebsd.org> <b649e5e0907091102h2bbf3799r4f8b840696a9162b@mail.gmail.com> <4A563A57.8090907@freebsd.org> <4A56AD55.2010201@freebsd.org> <4A56D6B7.8050100@freebsd.org> <4A56D87B.6000202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 Jul 2009, Andriy Gapon wrote: > Thinking aloud - maybe we could always use one value of tsc_freq (or > something like max_tsc_freq). This wouldn't give us correct timestamps when > TSC frequency is changing, but it would give us something that is always > proportional to TSC value and thus has its properties - monotonicity in the > first place. And, of course, there is no problem when TSC frequency is > constant. Just a point from a user perspective: I find it useful (important even) to be able to compare timing between runs on the same box, and while that means I need to control for the frequency changing in an experimental sense, in as much as timestamp measurements in dtrace can be normalized, that would be helpful. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0907101211480.10745>