Re: LTTng Time Stamp Issue

Re: LTTng Time Stamp Issue

[Jérémie Galarneau]

[-- Attachment #1.1: Type: text/plain, Size: 1441 bytes --]

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@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

[-- Attachment #1.2: Type: text/html, Size: 2718 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: LTTng Time Stamp Issue

[Mohamad Gebai]

[-- Attachment #1.1: Type: text/plain, Size: 2828 bytes --]

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@mathworks.in
> <mailto:Sai.Tujala@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


[-- Attachment #1.2: Type: text/html, Size: 6156 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Vlad]

[-- Attachment #1.1: Type: text/plain, Size: 3932 bytes --]

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 <mgebai@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@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


[-- Attachment #1.2: Type: text/html, Size: 8202 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Jonathan Rajotte-Julien]

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 <mgebai@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@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

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

[Vlad]

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-julien@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 <mgebai@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@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

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

[Jérémie Galarneau]

[-- Attachment #1.1: Type: text/plain, Size: 4375 bytes --]

On 22 May 2018 at 11:16, Vlad <vlad@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@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@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

[-- Attachment #1.2: Type: text/html, Size: 9618 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Jérémie Galarneau]

[-- Attachment #1.1: Type: text/plain, Size: 4956 bytes --]

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@efficios.com>
wrote:

>
>
> On 22 May 2018 at 11:16, Vlad <vlad@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@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@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

[-- Attachment #1.2: Type: text/html, Size: 11252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev