[lttng-dev] possible to configure LTTng to use a different CLOCK_* ? [Re: LTTng Time Stamp Issue]

Jérémie Galarneau jeremie.galarneau at efficios.com
Thu May 24 17:53:35 EDT 2018


On 22 May 2018 at 11:16, Vlad <vlad at demoninsight.com> wrote:

> Greetings,
>
> I have what I hope is a related question:
>
> - my use case is:
> - I use LTTng for userspace events only (at this time);
> - I have the system clock (CLOCK_REALTIME) driven by a PTP driver that
> comes with a NIC (SolarFlare) that slaves the system to an externally
> provided high-grade PTP master;
> - the NIC stamps all arriving IP packets at the hardware level and the
> driver then makes the timestamps available in userspace along with each
> packet;
> - I would like to be able to correlate these timestamps with LTTng
> timestamps on the same system.
>
> - is there a way to configure LTTng to use a user-specified CLOCK_* type?
> I understand that that would de-cohere the timestamps from other
> interesting timestamps (kernel events, etc) but my case above is valuable
> enough that I’d be willing to forgo everything else.
>

Hi Vlad,

lttng-ust's clock plug-in interface seems like a good fit for what you want.

Have a look at the example in lttng-ust's source tree:
https://github.com/lttng/lttng-ust/tree/master/doc/examples/clock-override

Thanks!
Jérémie


>
> Thank you in advance,
> Vlad
>
> On Apr 20, 2018, at 4:53 PM, Mohamad Gebai <mgebai at suse.de> wrote:
>
> LTTng uses the monotonic clock [1] to timestamp the event at trace-time.
> The monotonic clock is more appropriate than the real time (CLOCK_REALTIME)
> when you want to timestamp/compare/order certain events within the same
> system relatively to each other. Using the real time clock would cause a
> problem if say someone (or something, like ntp, or kvm in a VM) changed the
> system's time while tracing.
>
> With that being said, the monotonic clock doesn't give you a time that is
> very meaningful as a human (its reference is the system boot). Having the
> timestamps as an actual date and time would be more interesting. LTTng
> stores the real time at the beginning of the trace and stores it in the
> metadata, which is later used to convert the timestamps from monotonic time
> to real time. If you change the system's real time while tracing, it won't
> have any effect on the timestamps of the recorded events.
>
> Mohamad
>
> [1] https://linux.die.net/man/3/clock_gettime
> [2] http://linuxmogeb.blogspot.ca/2013/10/how-does-clockgettime-work.html
>
>
> On 04/20/2018 11:37 AM, Jérémie Galarneau wrote:
>
> Hi,
>
> I'm adding the LTTng mailing list in CC for the benefit of the community
> and so people add to or correct my explanation.
>
> The CTF specification describes the meaning of those fields:
> http://diamon.org/ctf/#spec8
>
> In your case, this means that the timestamps in the trace are expressed
> relative to an arbitrary time set 1524226572435601778 clock ticks after
> 00:00:00 on 1 January 1970.
>
> To take your specific example:
> Your clock is running at 1,000,000,000 Hz, meaning the duration of a clock
> tick (period) is of 1 ns.
>
> The event has occurred at
> 1524226572435601778 (offset) + 00000003827855360941 (event clock value)
> nanoseconds after UNIX Epoch. That leads us to around Friday, April 20,
> 2018 1:20:00 PM (GMT).
>
> Regards,
> Jérémie
>
>
>
> On 20 April 2018 at 11:06, Sai Tujala <Sai.Tujala at mathworks.in> wrote:
>
>> Hi Jeremie,
>>
>>
>>                 In metadata file of LTTng trace session,  offset from
>> Epoch is “1524226572435601778” and time stamp of an event in channel data
>> files is starting from “00000003827855360941”. Can you brief about
>> relevance between these two time stamps.
>>
>>
>> freq = 1000000000; /* Frequency, in Hz */
>>
>>         /* clock value offset from Epoch is: offset * (1/freq) */
>>
>>         offset = 1524226572435601778;
>>
>>
>>
>> Thanks & Regards,
>>
>> T Sai Kiran
>>
>>
>
>
>
> --
> Jérémie Galarneau
> EfficiOS Inc.
> http://www.efficios.com
>
>
> _______________________________________________
> lttng-dev mailing listlttng-dev at lists.lttng.orghttps://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
>
>


-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20180524/859b654e/attachment.html>


More information about the lttng-dev mailing list