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

[Jérémie Galarneau]

Just realized my e-mail client didn't show Jonathan's response. Sorry!

Jérémie

On 24 May 2018 at 17:53, Jérémie Galarneau <jeremie.galarneau at efficios.com>
wrote:

>
>
> 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
>
> _______________________________________________
> 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/2921f567/attachment-0001.html>