[LITMUS^RT] RT-litmus behaviour under real-workloads

[Ashraf E. Suyyagh]

Alright, thanks for your input and insight.

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

On 15 February 2018 at 04:20, Björn Brandenburg <bbb at mpi-sws.org> wrote:

>
> > On 15. Feb 2018, at 10:10, Ashraf E. Suyyagh <mrsuyyagh at gmail.com>
> wrote:
> >
> > 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.
>
> I sympathize, but I can’t help you with that. If you are stuck on the old
> version, you are ultimately on your own.
>
> > The benchmark and what it does is not the issue.
>
> The way the task is being set up might be relevant, but see below…
>
> > 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?
>
> 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.
>
> > 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.
>
> 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.
>
> > 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?
>
> You can either write your own tools to parse the old trace format or you
> will have to back-port the tools yourself.
>
> > I only need to know that they work fine before I move forward to doing
> some measurements.
>
> Again, we have much better support for this on newer versions…
>
> > 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?
>
> 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.
>
> - Björn
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20180215/3a727f44/attachment-0001.html>