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

[Björn Brandenburg]

> 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