From: Daniel.Thibault@drdc-rddc.gc.ca (Thibault, Daniel)
Subject: [lttng-dev] About Lttng trace mode
Date: Thu, 14 Nov 2013 17:01:25 +0000 [thread overview]
Message-ID: <48CF5AC71E61DB46B70D0F388054EFFD267A22BC@VAL-E-01.valcartier.drdc-rddc.gc.ca> (raw)
-----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)
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/>
next reply other threads:[~2013-11-14 17:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 17:01 Thibault, Daniel [this message]
2013-11-15 3:39 ` XIANG Hao
2014-02-03 16:03 ` Mathieu Desnoyers
-- strict thread matches above, loose matches on Subject: below --
2014-02-04 15:24 Thibault, Daniel
2013-11-14 13:24 XIANG Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48CF5AC71E61DB46B70D0F388054EFFD267A22BC@VAL-E-01.valcartier.drdc-rddc.gc.ca \
--to=daniel.thibault@drdc-rddc.gc.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox