[LITMUS^RT] HRT/SRT Schedulability

Tue Oct 7 20:31:47 CEST 2014

Hello Glen,

The missing/utilization problem of st_trace records (9/18-9/19) was
resolved by using rt_launch, not rtspin.

As you said, I'm getting runtime behavior, not theoretical analysis.
While running rt_launch, I could check the top result is gotten as expected:

  Utilization Expected Real  0.90 11% Cpu(s): 11.3%us,  0.8%sy,  0.0%ni,
87.6%id,  0.0%wa,  0.2%hi,  0.0%si,  0.0%st  1.80 23% Cpu(s): 22.5%us,
0.8%sy,  0.0%ni, 76.1%id,  0.4%wa,  0.2%hi,  0.0%si,  0.0%st  2.70 34% Cpu(s):
33.7%us,  0.7%sy,  0.0%ni, 65.4%id,  0.0%wa,  0.2%hi,  0.0%si,  0.0%st  3.60
45% Cpu(s): 44.9%us,  0.7%sy,  0.0%ni, 54.1%id,  0.1%wa,  0.2%hi,  0.0%si,
0.0%st  4.50 56% Cpu(s): 56.1%us,  0.7%sy,  0.0%ni, 43.0%id,  0.1%wa,
0.2%hi,  0.0%si,  0.0%st  5.40 68% Cpu(s): 67.1%us,  0.9%sy,  0.0%ni,
31.8%id,  0.1%wa,  0.1%hi,  0.0%si,  0.0%st  6.30 79% Cpu(s): 78.3%us,
0.8%sy,  0.0%ni, 20.7%id,  0.1%wa,  0.1%hi,  0.0%si,  0.0%st  7.20 90% Cpu(s):
89.4%us,  0.8%sy,  0.0%ni,  9.7%id,  0.0%wa,  0.1%hi,  0.0%si,  0.0%st

Using st_job_stats, I'm checking the traced information for all tasks and
the related jobs/period/response to check the deadline miss ratio.
All the jobs of each task are scheduled every period and they should meet
all deadline (HRT), for all tasks.

# Task,   Job,     Period,   Response, DL Miss?,   Lateness,  Tardiness
# task NAME=rt_launch PID=20342 COST=180000000 PERIOD=200000000 CPU=0
 20342,     2,  200000000,  180138369,        0,  -19861631,          0
 20342,     3,  200000000,  180108634,        0,  -19891366,          0
 20342,     4,  200000000,  180110191,        0,  -19889809,          0
 20342,     5,  200000000,  180115887,        0,  -19884113,          0
...

Now I'm increasing the running time of rt_launch and got a little bit
better result.
Even though more tests are needed, up to 56%, the schedulability is 1.
After that, it's dropped and fluctuated. Is this expected result?

Thanks,
Mikyung

On Tue, Oct 7, 2014 at 1:37 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:

>
> 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
>
>
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20141007/64fead66/attachment.html>