<div dir="ltr">Hi Aravind,<div><br></div><div>Did you have the chance to upgrade to 2.6.1.If so where you able to reproduce?</div><div><br></div><div>Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 1:07 PM, Aravind HT <span dir="ltr"><<a href="mailto:aravind.ht@gmail.com" target="_blank">aravind.ht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I have attached the complete profiling scripts here, its a bit shabby, im new to python.</div><div><br></div><div>There is a README which has the details on how to execute it. </div><div>Im using a Yocto 1.6 on x86_64 platforms on both the nodes. </div><div><br></div><div><br></div><div>Running this script when there are other sessions running seems to reproduce this problem easily.</div><div>Please try it and let me know if you have any issues reproducing the problem.<br></div><div><br></div><div>Regards,</div><div>Aravind.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 5, 2015 at 5:23 PM, Jérémie Galarneau <span dir="ltr"><<a href="mailto:jeremie.galarneau@efficios.com" target="_blank">jeremie.galarneau@efficios.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Dec 4, 2015 at 11:06 PM, Aravind HT <<a href="mailto:aravind.ht@gmail.com" target="_blank">aravind.ht@gmail.com</a>> wrote:<br>
> I am using 2.6.0 .I will try to share the code that I'm using here in some<br>
> time. If there are any specific fixes that are relevant to this issue, see<br>
> if you can provide a link to them. I would ideally like to try them out<br>
> before trying a full upgrade to the latest versions.<br>
<br>
</span>Hi,<br>
<br>
Can you provide more information on the system? Which distribution,<br>
architecture, kernel version?<br>
<br>
The verbose sessiond logs might help pinpoint any unexpected behaviour<br>
here (are all applications registering as expected?).<br>
<span><font color="#888888"><br>
Jérémie<br>
</font></span><div><div><br>
><br>
> On Fri, Dec 4, 2015 at 6:11 PM, Jérémie Galarneau<br>
> <<a href="mailto:jeremie.galarneau@efficios.com" target="_blank">jeremie.galarneau@efficios.com</a>> wrote:<br>
>><br>
>> Hi Aravind,<br>
>><br>
>> Can't say I have looked at everything you sent yet, but as a<br>
>> preemptive question, which version are we talking about here? 2.6.0 or<br>
>> 2.6.1? 2.6.1 contains a lot of relay daemon fixes.<br>
>><br>
>> Thanks,<br>
>> Jérémie<br>
>><br>
>> On Thu, Dec 3, 2015 at 7:01 AM, Aravind HT <<a href="mailto:aravind.ht@gmail.com" target="_blank">aravind.ht@gmail.com</a>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> > I am trying to obtain the performance characteristics of lttng with the<br>
>> > use<br>
>> > of test applications. Traces are being produced on a local node and<br>
>> > delivered to relayd that is running on a separate node for storage.<br>
>> ><br>
>> > An lttng session with the test applications producing an initial bit<br>
>> > rate of<br>
>> > 10 kb/s is started and run for about 30 seconds. The starting sub-buffer<br>
>> > size is kept at 128 kb and sub-buf count at 4. The session is then<br>
>> > stopped<br>
>> > and destroyed and traces are analyzed to see if there are any drops.<br>
>> > This is<br>
>> > being done in a loop with every subsequent session having an increment<br>
>> > of 2<br>
>> > kb/s as long as there are no drops. If there are drops, I increase the<br>
>> > buffer size by a factor of x2 without incrementing the bit rate.<br>
>> ><br>
>> > I see trace drops happening consistently with test apps producing traces<br>
>> > at<br>
>> > less than 40 kb/s, it doesnt seem to help even if I started with 1mb x 4<br>
>> > sub-buffers.<br>
>> ><br>
>> > Analysis :<br>
>> ><br>
>> > I have attached the lttng_relayd , lttng_consumerd_64 logs and the<br>
>> > entire<br>
>> > trace directory, hope you will be able to view it.<br>
>> > I have modified lttng_relayd code to dump the traces being captured in<br>
>> > the<br>
>> > lttng_relayd logs along with debug info.<br>
>> ><br>
>> > Each test app is producing logs in the form of  :<br>
>> > "TraceApp PID - 31940 THID - 31970 @threadRate - 1032 b/s appRate - 2079<br>
>> > b/s<br>
>> > threadTraceNum - 9 appTraceNum - 18  sleepTime - 192120"<br>
>> ><br>
>> > The test application PID, test application thread id, thread bit rate,<br>
>> > test<br>
>> > app bit rate, thread trace number and application trace number s are<br>
>> > part of<br>
>> > the trace. So in the above trace, the thread is producing at 1 kb/s and<br>
>> > the<br>
>> > whole test app is producing at 2 kb/s.<br>
>> ><br>
>> > If we look at the babeltrace out put, we see that the Trace with<br>
>> > TraceApp<br>
>> > PID - 31940 appTraceNum 2 is missing , with 1, 3, 4, 5 and so on being<br>
>> > successfully captured.<br>
>> > I looked at the lttng_relayd logs and found that trace of "appTraceNum<br>
>> > 2" is<br>
>> > not delivered/generated by the consumerd to the relayd in sequence with<br>
>> > other traces. To rule out that this is not a test application problem,<br>
>> > you<br>
>> > can look at line ltttng_relayd log : 12778 and see traces from<br>
>> > appTraceNum -<br>
>> > 1 to appTraceNum - 18 including the appTraceNum 2 are "re-delivered" by<br>
>> > the<br>
>> > consumerd to the relayd.<br>
>> > Essentially, I see appTraceNum 1 through appTraceNum 18 being delivered<br>
>> > twice, once individually where appTraceNum 2 is missing and once as a<br>
>> > group<br>
>> > at line 12778 where its present.<br>
>> ><br>
>> ><br>
>> > Request help with<br>
>> > 1. why traces are delivered twice, is it by design or a genuine problem<br>
>> > ?<br>
>> > 2. how to avoid traces being dropped even though buffers are<br>
>> > sufficiently<br>
>> > large enough ?<br>
>> ><br>
>> ><br>
>> > Regards,<br>
>> > Aravind.<br>
>> ><br>
>> > _______________________________________________<br>
>> > lttng-dev mailing list<br>
>> > <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
>> > <a href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jérémie Galarneau<br>
>> EfficiOS Inc.<br>
>> <a href="http://www.efficios.com" rel="noreferrer" target="_blank">http://www.efficios.com</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Jérémie Galarneau<br>
EfficiOS Inc.<br>
<a href="http://www.efficios.com" rel="noreferrer" target="_blank">http://www.efficios.com</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
lttng-dev mailing list<br>
<a href="mailto:lttng-dev@lists.lttng.org">lttng-dev@lists.lttng.org</a><br>
<a href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Jonathan Rajotte Julien<div><br></div></div></div></div></div>
</div>