[LITMUS^RT] Missing st_trace records

[Mikyung Kang]

Thanks, Björn! First of all, I want to get the number of jobs whose
deadline is not missed (including correct period-cost are shown) and total
number of jobs per task while launching tasks on physical
machine. Actually, I'm using your git branch to use st_job_stats [
https://github.com/brandenburg/sched-trace-tools]. Is this not the right
code for that?

Thanks,
Mikyung


On Thu, Nov 6, 2014 at 2:02 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:

>
> On 06 Nov 2014, at 18:00, Mikyung Kang <mkkang01 at gmail.com> wrote:
>
> > Even though I tried several $PROG, inter-run variation happened.
> > I pasted the result of 90% utilzation and 45% utilization cases below.
> > I used different (period,wcet) per task at this time.
> >
> > (1) 8 * 0.9 utilization/core ==> (4, 8, 5, 3, 2, 4, 8, 4, 1, 7) tasks
> are schedulable among 8 tasks. ==> schedulability (0.50, 1.00, 0.63, 0.38,
> 0.25, 0.50, 1.00, 0.50, 0.13, 0.88)
>
> How can a subset of a tasks be schedulable under G-EDF? As far as I know,
> no schedulability analysis has been published to date that would allow you
> to arrive at such a conclusion.
>
> Please, let's use a consistent terminology: NOT observing any deadline
> misses does NOT imply that a task set (or a task) is schedulable. The
> absence of observed faults cannot prove the correctness of a system.
>
> > (2) 5 * 0.9 utilization/core ==> (4, 5, 5, 5, 4, 5, 4, 5, 5, 5) tasks
> are schedulable among 5 tasks.
> > (3) 8 * 0.45 utilization/core ==> (4, 3, 7, 6, 4, 6, 4, 7, 6, 4) tasks
> are schedulable among 8 tasks.
> > (4) 5 * 0.45 utilization/core ==> (5, 2, 3, 4, 2, 3, 5, 4, 4, 3) tasks
> are schedulable among 5 tasks.
>
> I don't understand these calculations. How do you know the workload that
> you are launching is even feasible? In other words, why are you even
> surprised to see deadline misses?
>
> > That is, in case of 1st run of (1), 4 tasks have correct (period, cost)
> and the other 4 tasks have (period=0, cost=0).
> >
> > # Task,   Job,     Period,   Response, DL Miss?,   Lateness,  Tardiness
> > # task NAME=rt_launch PID=43217 COST=139000000 PERIOD=155000000 CPU=0
> >  43217,     2,  155000000,  139123829,        0,  -15876171,          0
> >  43217,     3,  155000000,  139120144,        0,  -15879856,          0
> >  43217,     4,  155000000,  139121134,        0,  -15878866,          0
> >  43217,     5,  155000000,  139113222,        0,  -15886778,          0
> > ...
> >
> > # task NAME=<unknown> PID=43215 COST=0 PERIOD=0 CPU=-1
> >  43215,     2,          0,  159116315,        0,  -17883685,          0
> >  43215,     3,          0,  159133056,        0,  -17866944,          0
> >  43215,     4,          0,  159121530,        0,  -17878470,          0
> >  43215,     5,          0,  159130841,        0,  -17869159,          0
> >  43215,     6,          0,  159142111,        0,  -17857889,          0
> >
> > Any hint/comments are welcome! I'll appreciate it!
>
> Glenn pointed this out already. If cost/period are equal to zero, then the
> ST_PARAM record is missing from the trace. You can easily verify this
> yourself by inspecting the st_job_stats source code. Missing records at the
> beginning of the trace most likely indicate that you are starting to trace
> only after the task has already been set up.
>
> - Björn
>
>
> _______________________________________________
> 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/20141106/cd2062d1/attachment.html>