Fantastic! Thank you for a prompt and helpful response (and shame on me for not checking the examples dir more carefully).
On May 22, 2018, at 11:34 AM, Jonathan Rajotte-Julien <jonathan.rajotte-jul...@efficios.com> wrote: > Hi Vlad, > > LTTng-ust does provide a clock override mechanism. > > See [1] for an example and some basic doc. > > Hope this cover your use case. > > Cheers > > [1] https://github.com/lttng/lttng-ust/tree/master/doc/examples/clock-override > > On Tue, May 22, 2018 at 11:16:20AM -0400, Vlad 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. >> >> 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 > > > -- > Jonathan Rajotte-Julien > EfficiOS _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
