[lttng-dev] About Lttng trace mode

[mathieu.desnoyers@efficios.com (Mathieu Desnoyers)]

----- Original Message -----
> From: "Daniel Thibault" <Daniel.Thibault@drdc-rddc.gc.ca>
> To: lttng-dev at lists.lttng.org
> Cc: "XIANG Hao" <Hao.Xiang at alcatel-sbell.com.cn>
> Sent: Thursday, November 14, 2013 12:01:25 PM
> Subject: Re: [lttng-dev] About Lttng trace mode
> 
> -----Message d'origine-----
> Date: Thu, 14 Nov 2013 13:24:16 +0000
> From: XIANG Hao <Hao.Xiang@alcatel-sbell.com.cn>
> 
> >   Could Lttng support transmit trace to host PC in a "live mode" or "fly
> >   mode" now? So as to reduce the buffer size requirement on the target
> >   board.
> >
> >   BTW, I read some material mentioned:
> >   The discard mode is used by default. In this mode, new trace data
> >   arriving to a full buffer are discarded. In overwrite mode, the oldest
> >   trace data in the buffer are discarded.
> >   This mode is also known as flight-recorder mode. Note however, that this
> >   refers to the internal buffers, not to the trace log storage. The
> >   discarding of events is marked in
> >   the trace log and can be noticed when the trace is analyzed. In this way
> >   the user can interactively adjust his trace settings.
> >
> >   What is the difference between "internal buffers" and "trace log
> >   storage"? Could the trace log storage be located in the host PC?
> >   For example: the target board transmit the trace to Host PC via TCP/UDP,
> >   and only a very little internal flight-recorder buffer is required in
> >   the target device. Is it feasible?
> 
>    Live mode is nearly ready; expect it with version 2.4.
> 
>    The difference between internal buffers and trace log storage goes like
>    this: the event providers write into a memory buffer (the internal
>    buffers), and at the same time the consumer daemon(s) withdraw event
>    records from the buffer and commit them to permanent storage (trace log
>    storage).  The buffer is broken down into a number of sub-buffers, and
>    each sub-buffer can only be accessed either by the writers (collectively)
>    or by the consumer.  In discard mode, while a sub-buffer is locked for
>    consumer access, should the writers go around the set of sub-buffers and
>    come up behind the consumer, their request to write into the consumer's
>    sub-buffer will be denied, and they will then discard the event they
>    wanted to record.  The "not to the trace log storage" bit is there to
>    clarify that no event record may ever be lost from the trace files once
>    it has been written into them: they can neither be discarded nor
>    overwritten.  (Actually, using the enable-channel tracefile-size and
>    tracefile-count options, you *can* set up an on-disk flight recorder, but
>    that is a different scenario)

The paragraph above is true, except for the part "while a sub-buffer is locked
for consumer access". In discard mode, as soon as the writer is filling up all
sub-buffers, and thus the produced sub-buffers count reaches the consumed
sub-buffer count minus the number of sub-buffers in the buffer (this is a buffer
full situation), events are discarded. This is done independently of whether or
not the consumer is currently locking a sub-buffer for reading.

Thanks,

Mathieu

> 
>    LTTng can already transmit the trace events to a host machine.  Going back
>    to the example of the writers writing into a memory buffer while the
>    consumer withdraws events from it, the consumer can be instructed to
>    transmit the records to a TCP address instead of writing them to local
>    file storage.  At that address, a relay daemon receives the records and
>    writes them to file storage.  Example:
> 
> (on the host machine:)
> $ lttng-relayd &
> (on the traced machine:)
> $ lttng create mysession --set-url net://host
> (enable events and channels, etc.)
> $ lttng start
> (.)
> $ lttng destroy
> 
> Daniel U. Thibault
> Protection des syst?mes et contremesures (PSC) | Systems Protection &
> Countermeasures (SPC)
> Cyber s?curit? pour les missions essentielles (CME) | Mission Critical Cyber
> Security (MCCS)
> R & D pour la d?fense Canada - Valcartier (RDDC Valcartier) | Defence R&D
> Canada - Valcartier (DRDC Valcartier)
> 2459 route de la Bravoure
> Qu?bec QC  G3J 1X5
> CANADA
> Vox : (418) 844-4000 x4245
> Fax : (418) 844-4538
> NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
> Gouvernement du Canada | Government of Canada
> <http://www.valcartier.drdc-rddc.gc.ca/>
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com