[lttng-dev] Clock correlation
mathieu.desnoyers at efficios.com
Wed Sep 19 10:11:31 EDT 2012
* Oestman, Fredrik (Fredrik_Oestman at mentor.com) wrote:
> We have a problem with kernel and ust traces not correlating in time
> when the option --clock-raw is used. We have used babeltrace
Author: Julien Desfossez <jdesfossez at efficios.com>
Date: Fri Aug 3 14:55:00 2012 -0400
Get rid of clock-raw and use real clock
The clock-raw does not make much sense except internally, using this
clock for seeks and with the public API is more complicated than
This patch replaces the clock-raw by a clock-cycles (does not scale the
timestamp with the frequency) and make sure all the calls that
manipulate timestamps use the timestamp in nanoseconds with the offset
That way the user of the API don't need to bother with the "raw"
timestamp which won't be convenient when dealing with multiple traces
taken in different timezones.
Traces output before and after this patch are exactly the same
and multiple API calls have been tested with real timestamps and
everything seems to work fine.
Signed-off-by: Julien Desfossez <jdesfossez at efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
which got into rc5.
This quickly phased-out the --clock-raw option, but introduced a
--clock-cycles that prints timestamps in cycles.
> I have noticed that version 1.0.0-rc5 doesn't have this
> option at all anymore. Why not?
The main reason for this change is the issue you noticed about lack of
time correlation when using the raw time. So instead of changing the
behavior of "--clock-raw", we decided to remove it, and provide a
similar feature (--clock-cycles) that does not impact timestamp
> Did anything change in the way
> timestamps and/or time offsets are generated in later versions of the
> kernel and/or user-space tracers? The traces were made with
> lttng-modules 2.0.3 and lttng-ust 2.0.5.
No changes were made to the way timestamps are generated, other than
small fixes (please refer to changelogs for details). This change is
internal to babeltrace, about the way it handle trace merge by
> Fredrik Östman
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
Operating System Efficiency R&D Consultant
More information about the lttng-dev