<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#0b5394">Alright, thanks for your input and insight. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#0b5394"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#0b5394">I would write a parser for the old st-trace tool if only I knew where to begin. There is no sufficient documentation of how the data is stored in the bin files, that is what is the formatting and order. Any clues/hints? Thanks</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 February 2018 at 04:20, Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 15. Feb 2018, at 10:10, Ashraf E. Suyyagh <<a href="mailto:mrsuyyagh@gmail.com">mrsuyyagh@gmail.com</a>> wrote:<br>
><br>
> Unfortunately, I am forced to use this release since it is the closest to Kernel 3.10 which has stable support for the Odroid-XU4. I am also using other tools which demand 3.10 kernel.<br>
<br>
</span>I sympathize, but I can’t help you with that. If you are stuck on the old version, you are ultimately on your own.<br>
<span class=""><br>
> The benchmark and what it does is not the issue.<br>
<br>
</span>The way the task is being set up might be relevant, but see below…<br>
<span class=""><br>
> The majority perform complex mathematical operations. Few, however, involve I/O, like decoding/encoding jpeg. Are there any issues if the tasks did I/O operations and not CPU bound in Litmus RT_mode? I read somewhere this is discouraged, is that true?<br>
<br>
</span>If your tasks block on I/O, you get a self-suspending real-time task. That’s perfectly fine for LITMUS^RT, but please do see the literature on self-suspending real-time tasks — analytically, this is not trivial.<br>
<span class=""><br>
> It is worth noting that I am using ft_tools 2016.1 against litmus 2014.2. The reason is that ft_tools 2014.2 did not have the st_trace_schedule, st_draw and st_job_stat. I have assumed that this is the culprit.<br>
<br>
</span>That’s definitely a major problem. You simply cannot use newer tools for older traces — the trace format changes with almost every release. This is why you are seeing bogus values in the traces. This simply doesn’t work. If you want to use the old version of LITMUS^RT, then you MUST also use the old user-space library and tools.<br>
<span class=""><br>
> Well, if I don't have access to st_trace_schedule and st_job_stats on 2014.2, what reliable methods I can use to debug my schedules?<br>
<br>
</span>You can either write your own tools to parse the old trace format or you will have to back-port the tools yourself.<br>
<span class=""><br>
> I only need to know that they work fine before I move forward to doing some measurements.<br>
<br>
</span>Again, we have much better support for this on newer versions…<br>
<span class=""><br>
> Running without forced completions crashes the system into a black unresponsive screen. Reboot required afterward. I still have no idea why. Any previous experience with this?<br>
<br>
</span>Then some of your jobs are failing to yield the CPU, i.e., monopolizing the CPU. This probably means that the code is not doing what you want it to do. I’d suggest to first debug the benchmark tasks on a recent version of LITMUS^RT and then, if you really have to, move to the older version once you know the benchmark itself is solid.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Björn<br>
<br>
<br>
</font></span></blockquote></div><br></div>