From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23651 invoked by alias); 24 Jan 2007 18:52:47 -0000 Received: (qmail 23622 invoked by uid 48); 24 Jan 2007 18:52:35 -0000 Date: Wed, 24 Jan 2007 18:52:00 -0000 Message-ID: <20070124185235.23621.qmail@sourceware.org> From: "joshua dot i dot stone at intel dot com" To: systemtap@sources.redhat.com In-Reply-To: <20070124160955.3916.fche@redhat.com> References: <20070124160955.3916.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug runtime/3916] improve timing monotony X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00191.txt.bz2 ------- Additional Comments From joshua dot i dot stone at intel dot com 2007-01-24 18:52 ------- If I may link to the relevant threads... The first report was here: http://sourceware.org/ml/systemtap/2007-q1/msg00174.html My reply tries to explain *why* the current implementation has this deficiency: http://sourceware.org/ml/systemtap/2007-q1/msg00175.html These further replies seem to confirm my hunch that the resync with kernel time is causing the negative intervals, as the resync happens in a timer callback (i.e. during softirq-timer). http://sourceware.org/ml/systemtap/2007-q1/msg00183.html http://sourceware.org/ml/systemtap/2007-q1/msg00184.html Possible solutions: * Find a better estimate of the cpu freq * Use a clock that's independent of cpu freq (e.g., a motherboard/chipset timer) * Get the kernel to provide a lockless gettimeofday * Others? -- http://sourceware.org/bugzilla/show_bug.cgi?id=3916 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.