<div dir="ltr">Hi,<div>The reason for reader timer option is, UST event throughput is very low so if I don't use this option I'm not at all getting UST trace data. Even though the difference between "reader-timer" and "switch-timer" is not clear for me. Correct me if I wrong,</div><div><br></div><div> "Switch-Timer": After switch timer expires, Consumer daemon will take the current sub-buffer data and new trace data will be written to next sub-buffer (if available). So switch between sub-buffer will happen.</div><div>"Reader-Timer": After Reader-Timer expires, Consumer daemon will check sub-buffer is full or not. If Full then consumer daemon will take the data or else consumer daemon won't take trace data.</div><div><br></div><div>I'm using my own application.</div><div><br></div><div>Thanks,</div><div>T SAI KIRAN.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 1, 2018 at 10:43 PM, Jonathan Rajotte-Julien <span dir="ltr"><<a href="mailto:jonathan.rajotte-julien@efficios.com" target="_blank">jonathan.rajotte-julien@efficios.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sai,<br>
<span class=""><br>
On Wed, Aug 01, 2018 at 10:05:30PM +0530, sai kiran wrote:<br>
> Hi,<br>
>  I'm using LTTng 2.9.4  version of lttng-tools, lttng-modules, and<br>
> lttng-ust. I'm doing tracing in Xilinx Zynq ZC706 evaluation kit.<br>
> the sequence of commands used for tracing:<br>
> Mode:<br>
> live mode.<br>
<br>
</span>What is the reason behind using the live feature here since you are running<br>
things locally (lttng-relayd/--set-url 127.0.0.1)?<br>
<br>
Are you doing live analysis or performing analysis after the<br>
fact?<br>
<br>
In other word, what are you trying to achieve with tracing?<br>
<br>
I just want to make sure that you are using the most appropriate way of tracing<br>
to achieve your goal.<br>
<span class=""><br>
> For relay daemon:<br>
> lttng-relayd -L tcp://127.0.0.1:5344--output=/<wbr>tmp/lttnglogs/<br>
> Session commds:<br>
> 1) lttng create my-session --live --set-url=net://<a href="http://127.0.0.1" rel="noreferrer" target="_blank">127.0.0.1</a><br>
> 2) lttng enable-channel --kernel --subbuf-size=131072 --num-subbuf=8<br>
> channel0<br>
> 3) lttng enable-channel -u --read-timer=2000000 channel0<br>
<br>
</span>Are you sure you want to use the read-timer option?<br>
<br>
Using 2000000 as its value mean that userspace subbuffers status will only be checked<br>
upon each 2 seconds.<br>
<span class=""><br>
> 4) lttng enable-event --kernel<br>
> sched_process_fork,sched_<wbr>process_exit,irq_handler_<wbr>entry,irq_handler_exit,sched_<wbr>switch,sched_waking<br>
> -c channel0 --session=my-session<br>
> 5) lttng enable-event -u kernelprofiler:kernelprofiler_<wbr>task_drop -c<br>
> channel0 --session=mysession<br>
> 6) lttng start<br>
> 7) lttng stop<br>
> 8) lttng destroy<br>
> <br>
> Here my application has a tracepoint of<br>
> "kernelprofiler:<wbr>kernelprofiler_task_drop"<br>
> event.<br>
> <br>
<br>
</span>> > Hi,<br>
> ><br>
> > After LTTng session is destroyed, no stream is “*Hung up*”. Continuously<br>
<br>
What do you mean by "Hung up"? Are you using babeltrace and connecting to the<br>
lttng-relayd daemon on localhost?<br>
<br>
What is your expectation?<br>
<br>
Do you mean that you are still receiving data on babeltrace side even when<br>
performing a lttng stop/destroy command?<br>
<br>
> > I’m getting data from “*relay daemon*”. I’ve killed consumer daemon, even<br>
<span class="">> > though tracing data coming from relay daemon.<br>
<br>
</span>This can happen if babeltrace is "catching-up" on the data, keep in mind that<br>
lttng-relayd have the trace data and can continue to send information to a<br>
babeltrace client even if the consumerd/sessiond is killed or the session<br>
stopped/destroyed.<br>
<span class=""><br>
> > Please help me. One more<br>
> > thing application is running infinitely.<br>
<br>
</span>Which application? Your application? Babeltrace? lttng-sessiond?<br>
<br>
If you are talking about your application, could you provide a backtrace<br>
indicating that ust is the culprit here?<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Jonathan Rajotte-Julien<br>
EfficiOS<br>
</font></span></blockquote></div><br></div>