[LITMUS^RT] running a task as its execution time

[Felipe Cerqueira]

2012/4/25 Giovani Gracioli <giovanig at gmail.com>

> So is there a way to ensure that the task will execute for its correct
> execution time?
>
> Giovani
>
>
Glenn is right, the problem is because you are forcing the loop to run for
WCET units of time. rtspin, for example, uses 90%.

Also, I'm not sure if all scheduling algorithms works with
PRECISE_ENFORCEMENT on. But you can check if the tasks are executing for
the right time using st_trace and unit-trace.
Have a look at Recording Scheduling Traces:
http://www.cs.unc.edu/~anderson/litmus-rt/doc/tracing.html

Could you change
     sleep_next_period();
to:
    wait_for_job_release(0); ?

And then use st_trace and unit-trace (visual mode) to visualize the results.



>
> On Wed, Apr 25, 2012 at 5:53 PM, Glenn Elliott <gelliott at cs.unc.edu>wrote:
>
>> A word of warning about using budget enforcement: There is currently no
>> way for the kernel to report back to the user program that the program has
>> exceeded its budget.  Your program will simply resume execution from where
>> it left off upon next job release, and not start a new program-level job.
>>
>> -Glenn
>>
>>
Glenn,

I saw that we can use wait_for_job_release() instead, because it compares
the number of the current job and the job to be released.
If the program is late, it checks the number of the job and doesn't block
(as sleep_next_period() would do).


>
>>
>> On Apr 25, 2012, at 3:58 PM, Felipe Cerqueira <felipeqcerqueira at gmail.com>
>> wrote:
>>
>> Hi Giovani,
>>
>> I've already faced something like that. The problem is that it's not safe
>> to measure time within the application.
>>
>> Your loop_once() code only keeps iterating and acessing memory. In that
>> case, I think there are only two factors causing the time difference. One
>> of the sources of the difference is that the task may be preempted while
>> you are measuring:
>>
>>         loop_start = read_tsc_us(); // reads from the TSC and converts to
>> microsecond
>>         tmp += loop_once();
>>         -> Suppose the task is preempted right here
>>         loop_end = read_tsc_us();
>>
>> Also, system interrupts may have ocurred between the measurements.
>>
>> In order to fix that, the application must communicate with the kernel.
>> But even so, I don't know if it is possible to synchronize perfectly the
>> loop in the code with the execution time of the task. The real-time job is
>> independent of the code it runs.
>>
>> The task will run according to the execution time you provided at the
>> initialization, but you can't check that via the application.
>> The only thing you can change is the WCET enforcement:
>>
>> sporadic_task_ns(ctx->exec_time * 1000, ctx->period * 1000, 0, 0,
>> RT_CLASS_HARD, QUANTUM_ENFORCEMENT, 0);
>>
>> Change to PRECISE_ENFORCEMENT if you want Litmus to use timers to enforce
>> the execution. I'm not so sure, but I think if you keep
>> QUANTUM_ENFORCEMENT, a completed job will only be removed until the next
>> quantum.
>>
>> Best Regards,
>> Felipe
>>
>> 2012/4/25 Giovani Gracioli <giovanig at gmail.com>
>>
>>> Hello,
>>>
>>> I am new at using LITMUS and I am facing some issues that maybe you can
>>> help. I want to make sure that a task will execute only for its pre-defined
>>> execution time, like this:
>>>
>>> //exec_time in microseconds
>>> int loop_for(unsigned int exec_time)
>>> {
>>>     int tmp = 0;
>>>     unsigned int elapsed = 0;
>>>     unsigned long long loop_start = 0, loop_end = 0;
>>>
>>>     while(elapsed < exec_time) {
>>>         loop_start = read_tsc_us(); // reads from the TSC and converts
>>> to microsecond
>>>         tmp += loop_once();
>>>         loop_end = read_tsc_us();
>>>         elapsed = elapsed + (loop_end - loop_start);
>>>     }
>>>
>>>    printf("elapsed = %d, exec_time = %d\n", elapsed, exec_time);
>>>
>>>     return tmp;
>>> }
>>>
>>> I choose the GSN-EDF scheduler by running "setsched" of liblitmus before
>>> running the test application. The problem is that, the most of times, the
>>> elapsed time is greater than the execution time. Here is a part of the
>>> output:
>>>
>>> elapsed = 13003, exec_time = 921
>>> elapsed = 12999, exec_time = 921
>>> elapsed = 13003, exec_time = 921
>>> elapsed = 13007, exec_time = 921
>>> elapsed = 13007, exec_time = 921
>>> elapsed = 12998, exec_time = 921
>>> elapsed = 12995, exec_time = 921
>>> elapsed = 12999, exec_time = 921
>>> elapsed = 12990, exec_time = 921
>>> elapsed = 921, exec_time = 921
>>> elapsed = 13002, exec_time = 921
>>>
>>> My guess is that the task is not running as a real-time task. Do I need
>>> to define any other parameter for LITMUS?
>>>
>>> The application source code and the kernel config files are attached on
>>> this email.
>>>
>>> Thanks in advance,
>>> Giovani
>>>
>>>
>>> _______________________________________________
>>> litmus-dev mailing list
>>> litmus-dev at lists.litmus-rt.org
>>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>>
>>>
>> _______________________________________________
>> litmus-dev mailing list
>> litmus-dev at lists.litmus-rt.org
>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>
>>
>> _______________________________________________
>> litmus-dev mailing list
>> litmus-dev at lists.litmus-rt.org
>> https://lists.litmus-rt.org/listinfo/litmus-dev
>>
>>
>
> _______________________________________________
> 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/20120425/d8bd3312/attachment.html>