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.galarn...@efficios.com> wrote: > > > On 22 May 2018 at 11:16, Vlad <v...@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 <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 >> listlttng-dev@lists.lttng.orghttps://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 >> >> >> > > > -- > 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 > > -- 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
