<div dir="ltr">Hi Björn,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 21, 2014 at 7:40 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi JP,<br>
<br>
thanks for reporting the issue. I'm not sure what's going on. Can you recreate the issue without the scripts (which are a black box to me) just by running & tracing a couple of rtspin instances?<br>
<span class=""><br></span></blockquote><div><br></div><div>Which traces are you interested in? I can recreate the 3-task system easily enough, and I can capture /dev/litmus/log. I can also use feather trace to get /dev/litmus/sched_traceX data. Poking around the list, I've seen recommendations to use the following to parse out the sched_trace logs:</div><div><br></div><div><a href="https://github.com/brandenburg/sched-trace-tools">https://github.com/brandenburg/sched-trace-tools</a><br></div><div><br></div><div>I pulled that down, and using the job_stats tool on the output from st_trace, I'm left with plaintext data that looks like below (one for each CPU). I'm probably doing something wrong though.</div><div><br></div><div><div>root@ubuntu-qemu:~/non-script.data# cat simple0</div><div># Task, Job, Period, Response, DL Miss?, Lateness, Tardiness</div><div># task NAME=<unknown> PID=3802 COST=0 PERIOD=0 CPU=-1</div><div> 3802, 9, 0, 30657540, 0, -29342460, 0</div><div> 3802, 13, 0, 32616504, 0, -27383496, 0</div><div> 3802, 39, 0, 30793032, 0, -29206968, 0</div><div> 3802, 89, 0, 29259038, 0, -30740962, 0</div><div> 3802, 93, 0, 29860287, 0, -30139713, 0</div><div> 3802, 97, 0, 29485435, 0, -30514565, 0</div><div> 3802, 101, 0, 30333923, 0, -29666077, 0</div><div> 3802, 131, 0, 30122722, 0, -29877278, 0</div><div> 3802, 135, 0, 30649661, 0, -29350339, 0</div><div># task NAME=<unknown> PID=3801 COST=0 PERIOD=0 CPU=-1</div></div><div><br></div><div>To be clear, what I'm doing is the following:</div><div><br></div><div><div>./rtspin 10 20 10 -w &</div><div>./rtspin 30 60 10 -w &</div><div>./rtspin 60 120 10 -w &</div></div><div>./release_ts<br></div><div><br></div><div>Then, in a second window, I simply run:</div><div>st_trace simple<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> On 20 Nov 2014, at 22:01, jp walters <<a href="mailto:mailinglistjp39@gmail.com">mailinglistjp39@gmail.com</a>> wrote:<br>
><br>
> root@ubuntu-qemu:~/experiment-scripts# ./parse_exps.py run-data/test1<br>
> Loading experiments...<br>
> Parsing data...<br>
> 0.00%<br>
> Writing csvs into parse-data...<br>
> Too little data to make csv files, printing results.<br>
<br>
</span>What does the above line mean?<br>
<span class=""><br></span></blockquote><div><br></div><div>I was hoping someone on the list might know. I assumed that this was normal, given the small system that I used.</div><div><br></div><div>thanks,</div><div>JP</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> <ExpPoint-run-data/test1><br>
> block-avg: Avg: 0.000 Max: 0.000 Min: 0.000 Var: 0.000<br>
> block-max: Avg: 0.000 Max: 0.000 Min: 0.000 Var: 0.000<br>
> miss-ratio: Avg: 1.000 Max: 1.000 Min: 1.000 Var: 0.000<br>
> record-loss: Avg: 0.000 Max: 0.000 Min: 0.000 Var: 0.000<br>
> tard-avg: Avg: 0.000 Max: 0.000 Min: 0.000 Var: 0.000<br>
> tard-max: Avg: 0.000 Max: 0.000 Min: 0.000 Var: 0.000<br>
><br>
> The 1.0 miss-ratio seems odd to me, given the resources available and the workload described in the 3 tasks example. Am I missing something?<br>
<br>
</span>This indeed seems odd. Miss _all_ deadlines? Even under moderate overload you would expect *some* jobs to complete before their deadlines. At the very least, the first jobs to be scheduled should not miss their deadlines.<br>
<br>
This means either that LITMUS^RT is somehow horribly broken or that the experimental setup isn't quite doing what it's supposed to. Let's try to narrow this down by using a simpler setup.<br>
<br>
Thanks,<br>
Björn<br>
<div class=""><div class="h5"><br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</div></div></blockquote></div><br></div></div>