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

[Giovani Gracioli]

So is there a way to ensure that the task will execute for its correct
execution time?

Giovani

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
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20120425/4641823a/attachment.html>