<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#0b5394">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.</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">The benchmark and what it does is not the issue. 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?</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">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.
<span style="color:rgb(11,83,148);font-family:verdana,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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? I only need to know that they work fine before I move forward to doing some measurements.</span>
</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">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?</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">Thanks</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"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 February 2018 at 03:48, 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 04:47, Ashraf E. Suyyagh <<a href="mailto:mrsuyyagh@gmail.com">mrsuyyagh@gmail.com</a>> wrote:<br>
><br>
> First of all, my apologies for the long post, but needed to cover the setup and results in details. I am forced to use litmus 2014.2 on a 3.10 kernel.<br>
<br>
</span>This version is ancient. You really should upgrade to the latest release. We don’t have the resources to support old versions, sorry.<br>
<span class=""><br>
> A sample command is running the bitcnts benchmark, the period is four times the WCET. Therefore, the implicit deadline is far away.<br>
> sudo ./bitcnts -p 1 -w 1502 6010 30 -- 1125000 &<br>
<br>
</span>Since I don’t know your code, I don’t really know what this does.<br>
<span class=""><br>
> I have run each of the benchmarks and they do execute periodically. So no problem in launching the benchmarks and I verified that my tasks are launching fine with correct results/outputs. However, the problems are the follows:<br>
> • When running st-trace-schedule and collecting results by st-job stats for one task, ACET values are odd. In many cases, they are 0, in others extremely high values which makes no sense (e.g. 3677604500000) (see file result_01<br>
<br>
</span>Yes, this makes no sense. Either the trace files are corrupt, or there’s some version mismatch, or something else fishy is going on. If the ACET values are garbage or implausible (which I haven’t seen before), then the trace is certainly not reliable.<br>
<br>
> • This issue is a frequent case with most benchmarks, I will list one as an example. In a task with a WCET of 107ms and a period of 500ms running for 30 seconds, the results are odd. The ACET shows as before, 0. And there are lots of forced jobs in a pattern of 1,1,0,1,1,0 ... etc or 0,1,0,10,1 ...etc. Why would the task be forced? The execution time is less than the WCET and the deadline is four times the WCET. There is no way I can imagine that the job would exceed its deadline. (see file result_02).<br>
<br>
Forced completions have nothing to do with deadlines.<br>
<br>
In any case, I would recommend to run without forced completions, especially when trying to debug scheduler behavior.<br>
<span class=""><br>
> Do note, in a previous project we have run those benchmarks tens of thousands of times each and we have a solid idea of how long they execute on average.<br>
<br>
</span>Note the words ‘on average’. But anyway this information is likely bogus because the trace is either corrupt or being wrongly parsed.<br>
<br>
> • Is the period capped? I have a task which is run as " sudo ./bitcnts -p 1 -w 1502 6010 30 -- 1125000 & ". However, the trace shows a period of 1715 instead of 6010<br>
<br>
There’s no period capping in LITMUS^RT. This just shows that the trace is not being parsed correctly.<br>
<span class=""><br>
> # Task, Job, Period, Response, DL Miss?, Lateness, Tardiness, Forced?, ACET, Preemptions, Migrations<br>
> # task NAME=bitcnts PID=4052 COST=1502000000 PERIOD=1715032704 CPU=1<br>
> 4052, 2, 1715032704, 1443401363, 0, -4566598637, 0, 0, 0, 0, 0<br>
> 4052, 3, 1715032704, 1446788641, 0, -4563211359, 0, 0, 0, 0, 0<br>
><br>
<br>
</span>Please try to reproduce this problem — bogus actual execution times and bogus trace information — on the latest LITMUS^RT version and on an x86 platform. (Presumably your test tasks are portable, so you should be able to run this easily on the latest version.) If the problem persists, please post an example that reproduces the issue. Otherwise, I’m afraid we won’t be able to look into this in more detail.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Björn<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>