[LITMUS^RT] HRT/SRT Schedulability

Glenn Elliott gelliott at cs.unc.edu
Tue Oct 7 19:37:04 CEST 2014


On Oct 7, 2014, at 1:21 PM, Mikyung Kang <mkkang01 at gmail.com> wrote:

> r="ltr">Hello all,
> 
> I'm trying to check schedulability for simple HRT/SRT task sets using Litmus-rt 2014.2.
> * 8 Cores, no hyper-threading, 16G memory
> * Bare-metal testing, Ubuntu 12.04 (Linux 3.10.41)
> * rt_launch program, 20-30 seconds
> 
> On top of clean OS and litmus-rt, only rt_launch is running and then st-*  trace files are recorded.
> I expected that all cases should be schedulable and c-edf result is better than g-edf result. 
> (At least, if Utilization <= 70% then c-edf schedulability >= 0.8)
> 
> But, as shown in the first following table and the second graph (bare-metal litmus-rt), 
> even w/ 45% CPUs utilization (6*(120,200)=3.6), the schedulability is dropped  so much and c-edf result isn't better than g-edf case.
> The schedulability for c-edf and g-edf (6th and 7th column) is an averaged value (20 times).
> 
> Based on other related papers, I expected that the schedulability (c-edf) will be larger than 0.7~0.8 (at least) up to 74.4% utilization (5.95).
> But, HRT and SRT, both cases produced around 0.5 schedulability. 
> 
> Even though I tried 1*(180,200) ~ 8*(180,200) as shown in the third graph, it's little bit better but still not good and fluctuation is happened.
> And, even though the utillization is similar, the schedulability is very different if the number of task sets is different.
> 
> Is this correct? How can I increase the schedulability? How can I see the difference between c-edf and g-edf?
> Is there anything that I should check for schedulability? Any tips to get best schedulability?
> 
> (1)
> num-tasks	period	wcet	utilization	ratio	bm-c-edf	bm-g-edf
> 4.00	200.00	60.00	1.20	15.0%	0.99	1.00
> 4.00	200.00	100.00	2.00	25.0%	1.00	0.99
> 5.00	200.00	110.00	2.75	34.4%	0.87	0.92
> 6.00	200.00	120.00	3.60	45.0%	0.64	0.79
> 6.00	200.00	145.00	4.35	54.4%	0.70	0.70
> 7.00	200.00	150.00	5.25	65.6%	0.49	0.51
> 7.00	200.00	170.00	5.95	74.4%	0.50	0.59
> 7.00	200.00	180.00	6.30	78.8%	0.57	0.50
> 7.00	200.00	190.00	6.65	83.1%	0.49	0.51
> 8.00	200.00	180.00	7.20	90.0%	0.41	0.41
> 
> (2)
> <bm.png>
> 
> (3) 1*(180,200) ~ 8*(180,200)
> <bm2.png>
>> 
> Thanks,
> Mikyung


Hi Mikyung,

What is your criteria for determining schedulability?  That is, what makes a task set unschedulable?  One deadline miss (HRT)?  A deadline miss of more than X time units (SRT)?  From your email, I get the feeling that you’re observing runtime behavior to determine schedulability, rather than theoretical analysis-based schedulability.  Is this correct?  If this is the case, what is the collective utilization of your tasks as reported by the *nix utility ‘top’?  Can you copy/paste the line that starts with “%Cpu(s)”?  The “%us” should be relatively close to what you provision with rt_launch.

Did you manage to resolve your problems you reported on last September?  The issues you reported made it sound like your system CPUs were experiencing much heavier load than you had expected (resulting in incomplete traces).

-Glenn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20141007/1924c521/attachment.html>


More information about the litmus-dev mailing list