[Bug runtime/3916] New: improve timing monotony

[Bug runtime/3916] New: improve timing monotony

[fche at redhat dot com]

As per several reports on the mailing list, the newer
gettimeofday_* calls are sometimes indicates time going
backward.  Let's see if that can be made rare.

-- 
           Summary: improve timing monotony
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


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.

[Bug runtime/3916] improve timing monotony

[joshua dot i dot stone at intel dot com]

------- 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.

[Bug runtime/3916] improve timing monotony

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  2007-01-24 19:13 -------
Also worth reading is one of our own design documents, which was since removed
from CVS:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/src/tapsets/timestamp/Attic/timestamp_tapset.txt?rev=1.1&content-type=text/plain&cvsroot=systemtap

-- 


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.

[Bug runtime/3916] improve timing monotony

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-01-24 19:32 -------
(In reply to comment #1)
> 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?

One simple thing is to keep the per-cpu counts from ever decreasing during
the resynchronization phase.  This could let them drift ahead of real time,
but so be it.  If it gets too bad, the runtime could emit a warning.
Also, the resync phase may not be necessary so frequently on stable_tsc
processors.

-- 


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.

[Bug runtime/3916] improve timing monotony

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  2007-06-07 02:15 -------
It seems that I like links.  Here's another relevant mailing-list discussion:
http://sourceware.org/ml/systemtap/2007-q2/msg00505.html

-- 


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.

[Bug runtime/3916] improve timing monotony

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-08-14 22:49 -------
(In reply to comment #4)
> It seems that I like links.  Here's another relevant mailing-list discussion:
> http://sourceware.org/ml/systemtap/2007-q2/msg00505.html

I updated my patch.
However, I think this still needs to be discussed (especially, 
about Core/Core2 architecture and newer AMD processors).

Thank you,


-- 


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.

[Bug runtime/3916] improve timing monotony

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-08-14 22:51 -------
Created an attachment (id=1968)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1968&action=view)
Initialize cpu_freq by using kernel variables

This patch changes systemtap's timer initialization 
to use kernel variable instead of estimating it. 

Masami


-- 


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.

[Bug runtime/3916] improve timing monotony

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  2007-08-16 16:17 -------
(In reply to comment #5)
> However, I think this still needs to be discussed (especially, 
> about Core/Core2 architecture and newer AMD processors).

There is a synthesized cpu feature flag X86_FEATURE_CONSTANT_TSC, added in
2.6.13 for x86_64 and 2.6.16 for i386.  Further, in 2.6.18 there's a tsc_khz
variable as a companion to the cpu_khz, and a check_tsc_unstable().

So hopefully we can make use of these features, though we'll need to gate it
with autoconf to continue supporting older kernels.

-- 


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.