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.
Thank you in advance,
Vlad
On Apr 20, 2018, at 4:53 PM, Mohamad Gebai <mge...@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.tuj...@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 list
>> lttng-dev@lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
