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
