[LITMUS^RT] Missing st_trace records

[Björn Brandenburg]

> On 06 Nov 2014, at 03:41, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> 
>> (3) I want to repeat test-case 20 times and then average their schedulability. In either case (whether including period=0 jobs are included to scheduled job or not), I could see that inter-run variation happened a lot as follows. Is this expected or not? Can you get consistent traced records (consistent fraction of schedulable task sets) any time??
>>  
>> 1.00 1.00 1.00 1.00 1.00 .13 1.00 1.00 1.00 .13 .13 1.00 .25 .13 .13 .13 .13 1.00 .25 1.00 

Is this data for one task, or for the entire task set? What exactly are these numbers—deadline miss ratios?

> What is the task set utilization?  Which scheduler do you use?  Under partition scheduling, you can still over-utilize a single processor even if task set utilization is not much more than 1.0 when your task partitioning is too imbalanced.  That is, you can overload one partition while all others are idle. Also, LitmusRT, being based upon Linux, may not support hard real-time scheduling all that well when task set utilization is high.  You may observe deadline misses from time to time.  You may want to examine the maximum amount by which a deadline is missed (perhaps normalized by relative deadline or period), rather than whether a deadline was ever missed.  

Also, if your system is NOT schedulable, under the implemented scheduling policies there is no guarantee (not just in LITMUS^RT, but in general) that the same task will always incur the same number of deadline misses. Which task incurs a deadline misses can depend on details such as the employed tie-breaking policy for tasks with equal deadlines, minuscule differences in arrival times, etc.

You might want to visualize these schedules and have a look—is there something “wrong” in the schedules with high deadline miss ratios, or is the task under analysis just “unlucky” in some schedules?

Can you post your scripts for setting up the experiments? If there is an issue, this might allow us to reproduce it.

Thanks,
Björn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20141106/96eafe66/attachment.html>