RTEMS time overflow problem

Tue Jun 30 06:29:42 UTC 2009

I think this time flow is due to tsim -freq option.
I am selecting freq = 65MHz for tsim.MOreover the evaluation version of tsim is limited to 32 bit time.

nasim
________________________________________
From: Joel Sherrill [joel.sherrill at oarcorp.com]
Sent: Tuesday, June 30, 2009 12:54 AM
To: Nasim Zehra
Cc: Thomas Doerfler; rtems-users at rtems.org
Subject: Re: RTEMS time overflow problem

Nasim Zehra wrote:
> i did not get your questions , but as far as i understood.the answers are
> i took priorities like 2,3 ,4 5,take less priority for the task having higher execution time.Because the shorter the period,higher the priority.Actually there are many problems causing confusion so i want a full fledge example.
> Like the number of ticks i told for each task is actually not their period,but equal to their execution time so i assigned priority according to their execution time although i should appply priority according to their periods.But i am selecting random periods for each task just to fullfill the requirement of upper bound situation on processor utilization factor.
> like for 4 tasks........U =( should be ) 75%
> so i selected period like that.....
> 246/2000 + 88/5000 + 848/3000 + 2202/8000 = 69% < 75% that must be and it is.
>
I may still be fuzzy headed from returning from the class in Munich
but this doesn't look like the right calculation.  It should be

execution time (in real time units) / period (in real time units)

So 1 millisecond CPU used with a period of 10 milliseconds is
10% of the CPU.

Also there are assumptions in RMS which cannot be met unless
you take great care.  (1) There ARE interrupts happening which
are not accounted for in any of the task CPU utilizations.
(2) When using an RTEMS with tick timing granularity, the timing
is relatively gross and the rounding/math will not help you.
Especially in the case where you might be close.  If you were
using an RTEMS version with nanosecond granularity on
the statistics, the numbers will be more precise.

But I really don't think those numbers look right above.
Are you really trying to do 8000 periods a second?  That's
an 125 microseconds per period.  What is your clock tick
configured as?  To support that with any level of accuracy,
you would have to have a VERY low value for the clock tick
and that alone would introduce a fairly significant amount
of overhead you are not measuring.

We need 3 pieces of information to confirm this:

1.  clock tick period configured
2.  period of each task in microseconds or milliseconds
3.  execution time of each task in microseconds of milliseconds

Something smells very fishy about the numbers you are providing

--joel

> above frcation is execution time ticks and below is period selected.
> would you like to send me some example so that i may understand.
>
There are multiple examples in the RTEMS source tree
and in the class-examples CVS module

--joel

> regards
> --------
> nasim
> ________________________________________
> From: Thomas Doerfler [Thomas.Doerfler at embedded-brains.de]
> Sent: Monday, June 29, 2009 8:35 PM
> To: Nasim Zehra; RTEMS Users Mailing List
> Subject: Re: RTEMS time overflow problem
>
> Hi,
>
> which priorities did you take?
>
> Please note: in general, rate monotonic works like a charm, so it would
> help to give more information, otherwise we will not be able to help you.
>
> And which tick period did you select?
>
> Any other tasks running?
>
> wkr,
> Thomas.
>
>
> Nasim Zehra wrote:
>
>> thomas
>>    yes i did .The mode of the tasks are preemptable and also i know that priorities  does not change in rate monotonic and i applied different priority to different task according to their execution time which was the criteria of rate monotonic.
>>
>> regards
>> ---
>> nasim zahra
>> ________________________________________
>> From: Thomas Dörfler [Thomas.Doerfler at embedded-brains.de]
>> Sent: Monday, June 29, 2009 6:32 PM
>> To: Nasim Zehra
>> Cc: rtems-users at rtems.org
>> Subject: Re: RTEMS time overflow problem
>>
>> Masim,
>>
>> unfortunately you did not mention how you created the tasks. did you
>> apply the scheduling priorities properly (Note: The rate monotonic
>> manager does NOT change task priorities. In just makes the tasks "ready"
>> at the proper time.).
>>
>> Did you make the tasks preemptable?
>>
>> wkr,
>> Thomas.
>>
>> Nasim Zehra wrote:
>>
>>> dear users
>>>    also tell me that if i select periods of tasks such that when they are executed ,they are in running condition and before they are deleted ,time over flow error is occurred.Is there any solution for that.
>>> i am having four tasks
>>> 1st--------executed in 2202 ticks
>>> 2nd-------// //            848
>>> 3rd-----------------------246
>>> 4th--------------------88
>>>  above mentioned ticks are equal to execution time of respective tasks.
>>> now i am selecting periods for them randomly so that upper bound condition for 4 tasks should be met according to rule of rate monotonic schedualing.like that
>>>  1st---------8000 period in terms of ticks
>>> 2nd---------3000
>>> 3rd---------2000
>>> 4th---------5000
>>>
>>> using these periods my U = 69.85%
>>> while theoritical U= 4(2(1/4) - 1)= 75.682%
>>>  so 69 %<75%
>>> => tasks are scheduable.
>>> but implementing it causes ime oveflow error on T simulator for leon3 processor.
>>>
>>> kindly help out.
>>>
>>> regards
>>> --------
>>> nasim
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>> --
>>
>> --------------------------------------------
>> Embedded Brains GmbH
>> Thomas Doerfler        Obere Lagerstrasse 30
>> D-82178 Puchheim       Germany
>> email: Thomas.Doerfler at embedded-brains.de
>> Phone: +49-89-18908079-2
>> Fax:   +49-89-18908079-9
>>
>
>
> --
>
> --------------------------------------------
> Embedded Brains GmbH
> Thomas Doerfler        Obere Lagerstrasse 30
> D-82178 Puchheim       Germany
> email: Thomas.Doerfler at embedded-brains.de
> Phone: +49-89-18908079-2
> Fax:   +49-89-18908079-9
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>