[ltt-dev] Question about timestamp using textDump module

[ltt-dev] Question about timestamp using textDump module

[Ya-Yunn Su]

Hi,
   I'm using lttng on a Xen environment.  I applied the lttng patch to 
the driver domain kernel and instrumented the driver domain.  I have a 
question about the timestamp in the textDump output.  From my 
understanding, the timestamp is in sec.nanosec format, so the difference 
between two entries is also in sec.nanosec format.  However, if I take 
the earlies and latest timestamp within a trace as the duration 
(hundreds of thousands second), it is much longer than the actual time I 
enable the tracing on (at most a minute).   Am I interpreting the 
timestamp wrong?  Any input is appreciated and thanks in advance.

Thanks,
Ya-Yunn

[ltt-dev] Question about timestamp using textDump module

[Mathieu Desnoyers]

* Ya-Yunn Su (yysu at nec-labs.com) wrote:
> Hi,
>   I'm using lttng on a Xen environment.  I applied the lttng patch to  
> the driver domain kernel and instrumented the driver domain.  I have a  
> question about the timestamp in the textDump output.  From my  
> understanding, the timestamp is in sec.nanosec format, so the difference  
> between two entries is also in sec.nanosec format.  However, if I take  
> the earlies and latest timestamp within a trace as the duration  
> (hundreds of thousands second), it is much longer than the actual time I  
> enable the tracing on (at most a minute).   Am I interpreting the  
> timestamp wrong?  Any input is appreciated and thanks in advance.

I assume you are running on x86 32 or 64 ?

LTTng extracts its timestamps from the cycle counters on these
architectures. It works well for architectures with stable cycle
counters, but we resort to work-arounds for architectures without stable
TSCs, which might skew the relation to "real time".

Please see http://lttng.org/content/documentation#manuals "Notes on
Asynchronous TSC Architectures (and workarounds)" for details.

Moreover, we have to look at what Xen does to the cycle counters of the
CPU. It might be playing with them underneath. In this case, we'd need a
Xen-specific trace clock hypercall.

Adding more precise support for x86 architectures without synchronized
TSCs is on the project todo list. Good progress has been done on ARM in
the past months, and it could be re-used for x86.

Thanks,

Mathieu

>
> Thanks,
> Ya-Yunn
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68