[lttng-dev] Clock correlation

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Wed Sep 19 10:11:31 EDT 2012

* Oestman, Fredrik (Fredrik_Oestman at mentor.com) wrote:
> Hi,
> We have a problem with kernel and ust traces not correlating in time
> when the option --clock-raw is used. We have used babeltrace
> 1.0.0-rc1.

See commit:

commit 03798a93f959f6c694fe98f5647481947607c604
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



> Cheers,
> Fredrik Östman
> http://go.mentor.com/sourceryanalyzer/
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.

More information about the lttng-dev mailing list