[Xenomai-help] resume/suspend periodic timing issue

[Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

I seem to have discovered a condition where if I have a thread in periodic
timing (system tick of 125000 ns) and my thread suspends itself based on
some condition, when I resume the thread later based on user input,
rt_task_wait_period() doesn't block until the thread has "caught up" with
where it should be. In other words, say I have a thread that is supposed to
run every 2 ms. I suspend it for 1 second, and then resume it.
rt_task_wait_period() will return immediately 50 times. This can be fixed by
calling rt_task_set_periodic() again after the thread's suspend call.

Is there any way around this?

Here is the thread in question: (2 ms period)

void meas_data::_meas_thread::task_func(void)
{
    meas_data::meas_update_data meas;
    const int display_hit = 25;
    
    int display_count=0;
        
    for(;;) {
        if(!motor->is_moving()) {
            meas.time = 0.0;
            display_count = 0;
            stop();
            set_period_ns(get_period_ns()); //fixes suspend/resume timing
        }
        else rt_task_wait_period();
        
        meas.force = motor->get_force();
        meas.lps = motor->get_linear();
        meas.sd = motor->get_limit_distal();
        meas.sp = motor->get_limit_proximal();
        meas.steps = motor->get_moved_steps();
        meas.time += 0.01;
        
/* log data to file */
        void *ptr = file_queue.alloc(sizeof(meas));
        assert(ptr);
        memcpy(ptr, &meas, sizeof(meas));
        file_queue.send(ptr, sizeof(meas));

/* display data on screen twice a second */
        if(++display_count>=display_hit) {
            display_count = 0;
            
            ptr = display_queue.alloc(sizeof(meas));
            assert(ptr);
            memcpy(ptr, &meas, sizeof(meas));
            display_queue.send(ptr, sizeof(meas));
        }
    }
}

When I resume the thread, I can see the data on the screen come in way too
fast until the thread "catches up." I have confirmed that it is
rt_task_wait_period() returning immediately.

Steven

Re: [Xenomai-help] resume/suspend periodic timing issue

[Gilles Chanteperdrix]

Steven Seeger wrote:
 > I seem to have discovered a condition where if I have a thread in periodic
 > timing (system tick of 125000 ns) and my thread suspends itself based on
 > some condition, when I resume the thread later based on user input,
 > rt_task_wait_period() doesn't block until the thread has "caught up" with
 > where it should be. In other words, say I have a thread that is supposed to
 > run every 2 ms. I suspend it for 1 second, and then resume it.
 > rt_task_wait_period() will return immediately 50 times. This can be fixed by
 > calling rt_task_set_periodic() again after the thread's suspend call.
 > 
 > Is there any way around this?

This behaviour is due to the way the overruns are accounted for: not
having called rt_task_wait_period while the periodic timer elapses is
currently considered an abnormal usage of the interface, and counted as
an overrun.

A way around this behaviour is to create an alarm object with
rt_alarm_create, and use rt_alarm_start and rt_alarm_wait for each
shot.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

I have never see an RTOS exhibit this behavior, and previous versions of
Fusion and the classic RTAI did not.

Steven


On 2/27/06 10:39 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> 
> This behaviour is due to the way the overruns are accounted for: not
> having called rt_task_wait_period while the periodic timer elapses is
> currently considered an abnormal usage of the interface, and counted as
> an overrun.
> 
> A way around this behaviour is to create an alarm object with
> rt_alarm_create, and use rt_alarm_start and rt_alarm_wait for each
> shot.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Gilles Chanteperdrix]

Steven Seeger wrote:
 > I have never see an RTOS exhibit this behavior, and previous versions of
 > Fusion and the classic RTAI did not.

In your opinion, rt_task_wait_period should return -ETIMEDOUT only once
and reset the overruns count ? How does the application get the overruns
count then ? With an additional function call ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

My "opinion" is that if a task is forcibly suspended, it should not accrue
overruns. This should only occur when a task is delayed or ready.

Steven


On 2/28/06 5:55 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> Steven Seeger wrote:
>> I have never see an RTOS exhibit this behavior, and previous versions of
>> Fusion and the classic RTAI did not.
> 
> In your opinion, rt_task_wait_period should return -ETIMEDOUT only once
> and reset the overruns count ? How does the application get the overruns
> count then ? With an additional function call ?

Re: [Xenomai-help] resume/suspend periodic timing issue

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

Steven Seeger wrote:
> My "opinion" is that if a task is forcibly suspended, it should not accrue
> overruns. This should only occur when a task is delayed or ready.

Just imagine that your task is attached to a continuously running timer
as soon as you request this via rt_task_set_periodic. So, if you feel
like suspending the task for a while, detach it from that timer again
(infinite period). Putting this functionality into the RTOS is a bit
overkill in my eyes.

This is a corner use-case, so not everyone should pay for implementing
it in a generic way, only the user who really wants it (by having to
write a few extra lines).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

Every other RTOS I've ever used would disagree with you. However, I can wrap
the suspend/resume functions with a call to set period. Thanks for the tip.

Steven

On 2/28/06 6:21 AM, "Jan Kiszka" <jan.kiszka@domain.hid> wrote:

> Steven Seeger wrote:
> Just imagine that your task is attached to a continuously running timer
> as soon as you request this via rt_task_set_periodic. So, if you feel
> like suspending the task for a while, detach it from that timer again
> (infinite period). Putting this functionality into the RTOS is a bit
> overkill in my eyes.
> 
> This is a corner use-case, so not everyone should pay for implementing
> it in a generic way, only the user who really wants it (by having to
> write a few extra lines).
> 
> Jan
> 

Re: [Xenomai-help] resume/suspend periodic timing issue

[Philippe Gerum]

Steven Seeger wrote:
> Every other RTOS I've ever used would disagree with you. However, I can wrap

set_periodic/wait_period are used to define a timeline, with a base period 
dedicated to process a bounded work cycle. If your application decides to kill the 
timeline by skipping work cycles voluntarily in order to process e.g. error states 
or interactive break, it needs to reset the timeline by calling set_periodic anew, 
which seems quite reasonable to do, since the old timeline is now dead in the 
water. If this is not some error recovery work or break state, but regular 
processing, then it should fit in the normal work cycle, otherwise there is no 
point in using set_periodic/wait_period to time it in the first place.

Beyond that, comparing with other RTOS behaviours does not fly that well, because 
some which actually implement this kind of construct might well raise an exception 
to some health manager entity for signaling the overrun (e.g. arinc653), in which 
case, one would end up having to hack the error handler so that it swallows those 
exceptions silently, for the interesting purpose of making a valid case out of an 
error case...

We could pass rt_task_wait_period() a pointer to an integer that would collect the 
count of overruns, and reset this count after the first overrun has been signaled. 
But this would not fix the initial problem in the application, though.

> the suspend/resume functions with a call to set period. Thanks for the tip.
> 
> Steven
> 
> On 2/28/06 6:21 AM, "Jan Kiszka" <jan.kiszka@domain.hid> wrote:
> 
> 
>>Steven Seeger wrote:
>>Just imagine that your task is attached to a continuously running timer
>>as soon as you request this via rt_task_set_periodic. So, if you feel
>>like suspending the task for a while, detach it from that timer again
>>(infinite period). Putting this functionality into the RTOS is a bit
>>overkill in my eyes.
>>
>>This is a corner use-case, so not everyone should pay for implementing
>>it in a generic way, only the user who really wants it (by having to
>>write a few extra lines).
>>
>>Jan
>>
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

It seems to me that the RTOS should just stop accruing overruns for any
suspended thread. What's the point of even allowing it to stay on the old
timeline? This algorithm, albeit implemented in kernel modules with classic
RTAI, never had an issue.

Well, everything works now with new set_periodic calls, so I guess we can
all be happy now.

Steven

On 2/28/06 7:10 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> Steven Seeger wrote:
>> Every other RTOS I've ever used would disagree with you. However, I can wrap
> 
> set_periodic/wait_period are used to define a timeline, with a base period
> dedicated to process a bounded work cycle. If your application decides to kill
> the 
> timeline by skipping work cycles voluntarily in order to process e.g. error
> states 
> or interactive break, it needs to reset the timeline by calling set_periodic
> anew, 
> which seems quite reasonable to do, since the old timeline is now dead in the
> water. If this is not some error recovery work or break state, but regular
> processing, then it should fit in the normal work cycle, otherwise there is no
> point in using set_periodic/wait_period to time it in the first place.
> 
> Beyond that, comparing with other RTOS behaviours does not fly that well,
> because 
> some which actually implement this kind of construct might well raise an
> exception 
> to some health manager entity for signaling the overrun (e.g. arinc653), in
> which 
> case, one would end up having to hack the error handler so that it swallows
> those 
> exceptions silently, for the interesting purpose of making a valid case out of
> an 
> error case...
> 
> We could pass rt_task_wait_period() a pointer to an integer that would collect
> the 
> count of overruns, and reset this count after the first overrun has been
> signaled. 
> But this would not fix the initial problem in the application, though.
> 

Re: [Xenomai-help] resume/suspend periodic timing issue

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

Steven Seeger wrote:
> It seems to me that the RTOS should just stop accruing overruns for any
> suspended thread. What's the point of even allowing it to stay on the old
> timeline? This algorithm, albeit implemented in kernel modules with classic
> RTAI, never had an issue.

Sorry, wildly suspending a periodic thread remains a very unusual design
in my eyes, and no RTOS should be hold responsible for this.

And "RTAI" is void argument: it's API has too many special
characteristics anyway to take this as a reference for anything else
than itself.

> 
> Well, everything works now with new set_periodic calls, so I guess we can
> all be happy now.
> 

Ack.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

How is this an unusual design?

I have a sound driver in my system that updates a DAC every 125 us. Should I
not suspend the thread after it's done playing? What should the thread do,
call rt_task_wait_period() every 125us, and contribute to unnecessary
overhead? 

Steven

On 2/28/06 7:27 AM, "Jan Kiszka" <jan.kiszka@domain.hid> wrote:
> Sorry, wildly suspending a periodic thread remains a very unusual design
> in my eyes, and no RTOS should be hold responsible for this.
> 
> And "RTAI" is void argument: it's API has too many special
> characteristics anyway to take this as a reference for anything else
> than itself.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

Steven Seeger wrote:
> How is this an unusual design?
> 
> I have a sound driver in my system that updates a DAC every 125 us. Should I
> not suspend the thread after it's done playing? What should the thread do,
> call rt_task_wait_period() every 125us, and contribute to unnecessary
> overhead? 

Simply stop the related timer when the job is done
(rt_task_setperiodic...). What should be the reason to keep *this*
particular timeline for the next output job? Does the DAC has its own
timer? Then you would have to synchronise on that one anyway. Otherwise,
you should better restart the periodic output as soon as the next job
arrives - with a new timeline. And it might be cleaner to use a real
synchronisation mechanism for the wakeup, something like an event or a
semaphore (suspend/resume is evil - mostly).

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

Well, the thread suspends when it's done playing, and when new data arrives
in the buffer via /dev/dsp, the thread is then resumed. I just wonder what
the point of suspend/resume is, then, if we're supposed to just use
rt_task_set_periodic to create a new timeline. Right now I am doing this,
and then suspending, and then before I resume, I make another timeline.

Steven

On 2/28/06 7:43 AM, "Jan Kiszka" <jan.kiszka@domain.hid> wrote:
> 
> Simply stop the related timer when the job is done
> (rt_task_setperiodic...). What should be the reason to keep *this*
> particular timeline for the next output job? Does the DAC has its own
> timer? Then you would have to synchronise on that one anyway. Otherwise,
> you should better restart the periodic output as soon as the next job
> arrives - with a new timeline. And it might be cleaner to use a real
> synchronisation mechanism for the wakeup, something like an event or a
> semaphore (suspend/resume is evil - mostly).
> 
> Jan
> 
> 

Re: [Xenomai-help] resume/suspend periodic timing issue

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Steven Seeger wrote:
> Well, the thread suspends when it's done playing, and when new data arrives
> in the buffer via /dev/dsp, the thread is then resumed. I just wonder what
> the point of suspend/resume is, then, if we're supposed to just use
> rt_task_set_periodic to create a new timeline. Right now I am doing this,
> and then suspending, and then before I resume, I make another timeline.
> 

Well, and this is racy in case the resume - for what reason ever - takes
place before the suspend. It will get lost then, and your player will
miss a job. One should better model this via an event (don't count
multiple wakeups) or a semaphore (each wakeup counts and is paired with
a wait in the player task).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

Actually the player would never miss a job, because the call to resume was
only made if the task is suspended. As with any /dev/dsp device, data in the
buffer has to be a certain size before it starts playing, so every call to
the driver's write command would check the state of the task and resume it
if necessary. :) It's crude but it works. I wrote that driver when I was
very inexperienced with RTOSs and was just using it as an example. I think
that code is over 4 years old.

Steven

On 2/28/06 8:01 AM, "Jan Kiszka" <jan.kiszka@domain.hid> wrote:

> Steven Seeger wrote:
>> Well, the thread suspends when it's done playing, and when new data arrives
>> in the buffer via /dev/dsp, the thread is then resumed. I just wonder what
>> the point of suspend/resume is, then, if we're supposed to just use
>> rt_task_set_periodic to create a new timeline. Right now I am doing this,
>> and then suspending, and then before I resume, I make another timeline.
>> 
> 
> Well, and this is racy in case the resume - for what reason ever - takes
> place before the suspend. It will get lost then, and your player will
> miss a job. One should better model this via an event (don't count
> multiple wakeups) or a semaphore (each wakeup counts and is paired with
> a wait in the player task).
> 
> Jan
> 

Re: [Xenomai-help] resume/suspend periodic timing issue

[Philippe Gerum]

Steven Seeger wrote:
> It seems to me that the RTOS should just stop accruing overruns for any
> suspended thread. What's the point of even allowing it to stay on the old
> timeline?

Because set_periodic/wait_period are about defining a series of absolute dates 
forming a continuous timeline, the fact that a thread goes suspending instead of 
waiting for the next work cycle does not change the fact that the clock is still 
ticking.

  This algorithm, albeit implemented in kernel modules with classic
> RTAI, never had an issue.
> 
> Well, everything works now with new set_periodic calls, so I guess we can
> all be happy now.
> 
> Steven
> 
> On 2/28/06 7:10 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:
> 
> 
>>Steven Seeger wrote:
>>
>>>Every other RTOS I've ever used would disagree with you. However, I can wrap
>>
>>set_periodic/wait_period are used to define a timeline, with a base period
>>dedicated to process a bounded work cycle. If your application decides to kill
>>the 
>>timeline by skipping work cycles voluntarily in order to process e.g. error
>>states 
>>or interactive break, it needs to reset the timeline by calling set_periodic
>>anew, 
>>which seems quite reasonable to do, since the old timeline is now dead in the
>>water. If this is not some error recovery work or break state, but regular
>>processing, then it should fit in the normal work cycle, otherwise there is no
>>point in using set_periodic/wait_period to time it in the first place.
>>
>>Beyond that, comparing with other RTOS behaviours does not fly that well,
>>because 
>>some which actually implement this kind of construct might well raise an
>>exception 
>>to some health manager entity for signaling the overrun (e.g. arinc653), in
>>which 
>>case, one would end up having to hack the error handler so that it swallows
>>those 
>>exceptions silently, for the interesting purpose of making a valid case out of
>>an 
>>error case...
>>
>>We could pass rt_task_wait_period() a pointer to an integer that would collect
>>the 
>>count of overruns, and reset this count after the first overrun has been
>>signaled. 
>>But this would not fix the initial problem in the application, though.
>>
> 
> 
> 


-- 

Philippe.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

Right, so if a thread is suspended voluntarily it should just ignore the
clock tick. I think I will read more about RTOSs and see if I change my
mind, but for now I think that this is a poor design on our part. However,
xenomai is what I fought hard to use for these projects, so I guess I'll
have to stick with it. :)

Steven

On 2/28/06 7:29 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> Because set_periodic/wait_period are about defining a series of absolute dates
> forming a continuous timeline, the fact that a thread goes suspending instead
> of 
> waiting for the next work cycle does not change the fact that the clock is
> still 
> ticking.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Philippe Gerum]

Steven Seeger wrote:
> Right, so if a thread is suspended voluntarily it should just ignore the
> clock tick.

Precisely not, it should be aware that time keeps advancing regardless of its own 
status, suspended or not.

  I think I will read more about RTOSs and see if I change my
> mind, but for now I think that this is a poor design on our part. However,
> xenomai is what I fought hard to use for these projects, so I guess I'll
> have to stick with it. :)
> 
> Steven
> 
> On 2/28/06 7:29 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:
> 
> 
>>Because set_periodic/wait_period are about defining a series of absolute dates
>>forming a continuous timeline, the fact that a thread goes suspending instead
>>of 
>>waiting for the next work cycle does not change the fact that the clock is
>>still 
>>ticking.
> 
> 
> 


-- 

Philippe.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

If time stopped for you, would you be aware of anything?

On 2/28/06 8:20 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> 
> Precisely not, it should be aware that time keeps advancing regardless of its
> own 
> status, suspended or not.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Philippe Gerum]

Steven Seeger wrote:
> If time stopped for you, would you be aware of anything?
> 

The global timeline the whole RTOS is working on does not stop for suspended 
threads, this is what you seem to be missing since the very beginning of this 
discussion. For instance, forcibly suspending a task (e.g. using rt_task_suspend) 
while it is already undergoing a blocked state with a timeout (e.g. pending on 
some sempahore to become available, whatever) does not prevent the timeout to be 
decremented tick after tick. This is called cumulative suspension states, and all 
the RTOS I know of enforce that. Fortunately.

> On 2/28/06 8:20 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:
> 
> 
>>Precisely not, it should be aware that time keeps advancing regardless of its
>>own 
>>status, suspended or not.
> 
> 
> 


-- 

Philippe.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Steven Seeger]

All right, all right. I surrender. *waves the white flag*

Let's just say that I saw something different from fusion/classic RTAI and
was reporting it as a possible bug incorrectly, all right?

I'll still have to send you a bill. :)

Steven

On 2/28/06 8:37 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> The global timeline the whole RTOS is working on does not stop for suspended
> threads, this is what you seem to be missing since the very beginning of this
> discussion. For instance, forcibly suspending a task (e.g. using
> rt_task_suspend) 
> while it is already undergoing a blocked state with a timeout (e.g. pending on
> some sempahore to become available, whatever) does not prevent the timeout to
> be 
> decremented tick after tick. This is called cumulative suspension states, and
> all 
> the RTOS I know of enforce that. Fortunately.

[Xenomai-core] rt_task_wait_period() and overruns

[Philippe Gerum]

Steven Seeger wrote:
> All right, all right. I surrender. *waves the white flag*
> 
> Let's just say that I saw something different from fusion/classic RTAI and
> was reporting it as a possible bug incorrectly, all right?
> 

Right (except that fusion never exhibited the behaviour you described, though). 
Still, there is an interesting question that remains which you indirectly brought 
in, and which is the real issue to worry about: does rt_task_wait_period(), as it 
is now, behave in the best interest of users who happen to use it properly?

I mean: if the application misses several deadlines because something is going 
wild in there, wouldn't the recovery procedure be easier if one knows at once how 
many deadlines have been missed in a raw, without having to call the RTOS back. 
IOW, do we want to purge the overrun count after the first notification and make 
rt_task_wait_period return this count (e.g. ala Chorus/OS's thread pools), or 
would it be preferable to keep the things the way they are now?

Breaking the API again is also an issue, albeit we already broke it for a few 
other calls when working on v2.1 anyway.

Open question. Something like a poll, actually.

-- 

Philippe.

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

[Philippe Gerum]

Philippe Gerum wrote:
> Steven Seeger wrote:
> 
>> All right, all right. I surrender. *waves the white flag*
>>
>> Let's just say that I saw something different from fusion/classic RTAI 
>> and
>> was reporting it as a possible bug incorrectly, all right?
>>
> 
> Right (except that fusion never exhibited the behaviour you described, 
> though). Still, there is an interesting question that remains which you 
> indirectly brought in, and which is the real issue to worry about: does 
> rt_task_wait_period(), as it is now, behave in the best interest of 
> users who happen to use it properly?
> 
> I mean: if the application misses several deadlines because something is 
> going wild in there, wouldn't the recovery procedure be easier if one 
> knows at once how many deadlines have been missed in a raw,

"in a row". Typical froggie English, sorry.

  without
> having to call the RTOS back. IOW, do we want to purge the overrun count 
> after the first notification and make rt_task_wait_period return this 
> count (e.g. ala Chorus/OS's thread pools), or would it be preferable to 
> keep the things the way they are now?
> 
> Breaking the API again is also an issue, albeit we already broke it for 
> a few other calls when working on v2.1 anyway.
> 
> Open question. Something like a poll, actually.
> 


-- 

Philippe.

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

[Steven Seeger]

I do not recall having this problem with fusion, but I'll take your word on
it. I don't have time to go back and check. :)

Purging the overrun count when rt_task_wait_period() is called may work but
not for all conditions. For example, say I am monitoring a patient's
heartbeat by taking an A/D reading every 1 ms in order to build an ECG
waveform. If I have 4 overruns, I've got a problem because I've missed
crucial data, and this is a serious problem. Of course, it isn't the RTOS's
job to create an error condition in this fashion. But on the other hand, it
woudln't be desirable to have 4 duplicate measurements in such a waveform,
either. The user could check the overrun count himself already, if desired.

The problem with purging the overrun count is that a lot of periodic threads
use counters to perform certain actions. Say my thread runs every 1 ms, so
every 500 times I want to toggle an LED to make it blink at a rate of 2 Hz.
If the overrun counter is purged, then such behavior is going to mess up the
counter. If there is a momentary loss of realtime due to a higher priorituy
thread going nuts, the light will still most likely blink at the right time.

Perhaps the best option would be to make this a task property that users can
set? Keep the current behavior by default, but purge overruns if they so
desire. The cost of this would be only one branch condition in
rt_task_wait_period().

Steven


On 2/28/06 9:53 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> Steven Seeger wrote:
> Right (except that fusion never exhibited the behaviour you described,
> though). 
> Still, there is an interesting question that remains which you indirectly
> brought 
> in, and which is the real issue to worry about: does rt_task_wait_period(), as
> it 
> is now, behave in the best interest of users who happen to use it properly?
> 
> I mean: if the application misses several deadlines because something is going
> wild in there, wouldn't the recovery procedure be easier if one knows at once
> how 
> many deadlines have been missed in a raw, without having to call the RTOS
> back. 
> IOW, do we want to purge the overrun count after the first notification and
> make 
> rt_task_wait_period return this count (e.g. ala Chorus/OS's thread pools), or
> would it be preferable to keep the things the way they are now?
> 
> Breaking the API again is also an issue, albeit we already broke it for a few
> other calls when working on v2.1 anyway.
> 
> Open question. Something like a poll, actually.

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

[Philippe Gerum]

Steven Seeger wrote:
> I do not recall having this problem with fusion, but I'll take your word on
> it. I don't have time to go back and check. :)
> 
> Purging the overrun count when rt_task_wait_period() is called may work but
> not for all conditions. For example, say I am monitoring a patient's
> heartbeat by taking an A/D reading every 1 ms in order to build an ECG
> waveform. If I have 4 overruns, I've got a problem because I've missed
> crucial data, and this is a serious problem. Of course, it isn't the RTOS's
> job to create an error condition in this fashion. But on the other hand, it
> woudln't be desirable to have 4 duplicate measurements in such a waveform,
> either. The user could check the overrun count himself already, if desired.
> 
> The problem with purging the overrun count is that a lot of periodic threads
> use counters to perform certain actions. Say my thread runs every 1 ms, so
> every 500 times I want to toggle an LED to make it blink at a rate of 2 Hz.
> If the overrun counter is purged, then such behavior is going to mess up the
> counter. If there is a momentary loss of realtime due to a higher priorituy
> thread going nuts, the light will still most likely blink at the right time.
> 
> Perhaps the best option would be to make this a task property that users can
> set? Keep the current behavior by default, but purge overruns if they so
> desire. The cost of this would be only one branch condition in
> rt_task_wait_period().
>

I'm not sure to get your point clearly, yet. The other option I've described for 
dealing with overruns in rt_task_wait_period would be as follows:

- save the count of overruns
- clear the count of overruns  /* i.e. "purge" */
- return both the saved count and -ETIMEDOUT to the user.

This way, rt_task_wait_period would return only once with an error status, telling 
the user about the exact count of pending overruns in the same time. In that case, 
the application code would be free to take all needed actions so that its results 
would not be polluted by the multiple overruns. In the waveform case, this would 
precisely allow not to log invalid data that would otherwise be obtained by 
spinning without waiting through multiple calls to rt_task_wait_period. In the 
counter example, nothing would prevent you from updating such counter once with 
the returned number of overruns.

> Steven
> 
> 
> On 2/28/06 9:53 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:
> 
> 
>>Steven Seeger wrote:
>>Right (except that fusion never exhibited the behaviour you described,
>>though). 
>>Still, there is an interesting question that remains which you indirectly
>>brought 
>>in, and which is the real issue to worry about: does rt_task_wait_period(), as
>>it 
>>is now, behave in the best interest of users who happen to use it properly?
>>
>>I mean: if the application misses several deadlines because something is going
>>wild in there, wouldn't the recovery procedure be easier if one knows at once
>>how 
>>many deadlines have been missed in a raw, without having to call the RTOS
>>back. 
>>IOW, do we want to purge the overrun count after the first notification and
>>make 
>>rt_task_wait_period return this count (e.g. ala Chorus/OS's thread pools), or
>>would it be preferable to keep the things the way they are now?
>>
>>Breaking the API again is also an issue, albeit we already broke it for a few
>>other calls when working on v2.1 anyway.
>>
>>Open question. Something like a poll, actually.
> 
> 
> 


-- 

Philippe.

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

[Dmitry Adamushko]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

On 01/03/06, Philippe Gerum <rpm@xenomai.org> wrote:


 The other option I've described for
> dealing with overruns in rt_task_wait_period would be as follows:
>
> - save the count of overruns
> - clear the count of overruns  /* i.e. "purge" */
> - return both the saved count and -ETIMEDOUT to the user.
>
> This way, rt_task_wait_period would return only once with an error status,
> telling
> the user about the exact count of pending overruns in the same time.



I definitely agree with you here.

IMHO, there is no point in calling rt_task_wait_period() a few
times in a row just to clean up the "poverrun" counter
(if there were a few overruns) when the whole may be reported at once. This
former way just gives unnecessary overhead.


Actually, there is a kind of application that must not rely on
the "poverrun" counter, the klatency/latency utility and alike.

They are run normally (at least at the very first time) in the untrusted
environment
where SMI or something similar - that may prevent a CPU from handling normal
interrupts for quite a long time - make occur happily.
As the "poeverrun" counting is dependent on the timer interrupt,
it becomes irrelevant.

Something like
overruns = (real_time_of_wakeup - desired_time_of_wakeup) / period (*)
should be rather used there (of course, the timing source must not be
interrupt-dependent).

Other applications may likely rely on the "poverrun" counter
(returned by rt_task_wait_period(&overrun)) as they normally
run in the (more or less) studied and tweaked environment.

Ok, some "paranoid" programmers would think differently even then
but there is always the (*) way :o)


--
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 2231 bytes --]

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

[Philippe Gerum]

Dmitry Adamushko wrote:
> 
> On 01/03/06, *Philippe Gerum* <rpm@xenomai.org <mailto:rpm@xenomai.org>> 
> wrote:
>  
> 
>      The other option I've described for
>     dealing with overruns in rt_task_wait_period would be as follows:
> 
>     - save the count of overruns
>     - clear the count of overruns  /* i.e. "purge" */
>     - return both the saved count and -ETIMEDOUT to the user.
> 
>     This way, rt_task_wait_period would return only once with an error
>     status, telling
>     the user about the exact count of pending overruns in the same time. 
> 
> 
> 
> I definitely agree with you here.
> 
> IMHO, there is no point in calling rt_task_wait_period() a few
> times in a row just to clean up the "poverrun" counter
> (if there were a few overruns) when the whole may be reported at once. 
> This former way just gives unnecessary overhead.
> 

My concern is that some recovery procedure might require to get the exact number 
of pending overruns to operate properly in order to catch up with the missing 
expiries, and there is no way to get this information out of the current API (!). 
Even calling rt_task_wait_period in loop and testing for -ETIMEDOUT is unusable, 
since well, we would obviously get blocked when the overrun count drops to zero, 
which is not what we want in order to be able to run the recovery procedure asap.

> 
> Actually, there is a kind of application that must not rely on
> the "poverrun" counter, the klatency/latency utility and alike.
> 
> They are run normally (at least at the very first time) in the untrusted 
> environment
> where SMI or something similar - that may prevent a CPU from handling normal
> interrupts for quite a long time - make occur happily.
> As the "poeverrun" counting is dependent on the timer interrupt,
> it becomes irrelevant.
> 
> Something like
> overruns = (real_time_of_wakeup - desired_time_of_wakeup) / period (*)
> should be rather used there (of course, the timing source must not be
> interrupt-dependent).

Ah! you know what, I'm pretty sure that one of your very first public posts on the 
RTAI/fusion mailing list at that time, was exactely about this issue :o) And yes, 
this is correct, we currently rely on some internal accounting that depends on the 
system's ability to get properly paced timer ticks, which is, mmh... silly. I'm 
the one to congratulate for that.

> 
> Other applications may likely rely on the "poverrun" counter
> (returned by rt_task_wait_period(&overrun)) as they normally
> run in the (more or less) studied and tweaked environment.
> 
> Ok, some "paranoid" programmers would think differently even then
> but there is always the (*) way :o)
> 
> 
> -- 
> Best regards,
> Dmitry Adamushko


-- 

Philippe.

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

[Dmitry Adamushko]

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

On 01/03/06, Philippe Gerum <rpm@xenomai.org> wrote:
>
> Dmitry Adamushko wrote:
> >
> > On 01/03/06, *Philippe Gerum* <rpm@xenomai.org <mailto:rpm@xenomai.org>>
> > wrote:
> >
> >
> >      The other option I've described for
> >     dealing with overruns in rt_task_wait_period would be as follows:
> >
> >     - save the count of overruns
> >     - clear the count of overruns  /* i.e. "purge" */
> >     - return both the saved count and -ETIMEDOUT to the user.
> >
> >     This way, rt_task_wait_period would return only once with an error
> >     status, telling
> >     the user about the exact count of pending overruns in the same time.
> >
> >
> >
> > I definitely agree with you here.
> >
> > IMHO, there is no point in calling rt_task_wait_period() a few
> > times in a row just to clean up the "poverrun" counter
> > (if there were a few overruns) when the whole may be reported at once.
> > This former way just gives unnecessary overhead.
> >
>
> My concern is that some recovery procedure might require to get the exact
> number
> of pending overruns to operate properly in order to catch up with the
> missing
> expiries, and there is no way to get this information out of the current
> API (!).
> Even calling rt_task_wait_period in loop and testing for -ETIMEDOUT is
> unusable,
> since well, we would obviously get blocked when the overrun count drops to
> zero,
> which is not what we want in order to be able to run the recovery
> procedure asap.


All in all, I would vote for changing the current rt_task_wait_period()
interface.



>
> > Actually, there is a kind of application that must not rely on
> > the "poverrun" counter, the klatency/latency utility and alike.
> >
> > They are run normally (at least at the very first time) in the untrusted
> > environment
> > where SMI or something similar - that may prevent a CPU from handling
> normal
> > interrupts for quite a long time - make occur happily.
> > As the "poeverrun" counting is dependent on the timer interrupt,
> > it becomes irrelevant.
> >
> > Something like
> > overruns = (real_time_of_wakeup - desired_time_of_wakeup) / period (*)
> > should be rather used there (of course, the timing source must not be
> > interrupt-dependent).
>
> Ah! you know what, I'm pretty sure that one of your very first public
> posts on the
> RTAI/fusion mailing list at that time, was exactely about this issue :o)


Good memory indeed; so it's too earlier for you to get retired :o)


--
>
> Philippe.
>



--
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 3656 bytes --]

[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

[Philippe Gerum]

Dmitry Adamushko wrote:
> 
> On 01/03/06, *Philippe Gerum* <rpm@xenomai.org <mailto:rpm@xenomai.org>> 
> wrote:
> 
>     Dmitry Adamushko wrote:
>      >
>      > On 01/03/06, *Philippe Gerum* <rpm@xenomai.org
>     <mailto:rpm@xenomai.org> <mailto:rpm@xenomai.org
>     <mailto:rpm@xenomai.org>>>
>      > wrote:
>      >
>      >
>      >      The other option I've described for
>      >     dealing with overruns in rt_task_wait_period would be as follows:
>      >
>      >     - save the count of overruns
>      >     - clear the count of overruns  /* i.e. "purge" */
>      >     - return both the saved count and -ETIMEDOUT to the user.
>      >
>      >     This way, rt_task_wait_period would return only once with an
>     error
>      >     status, telling
>      >     the user about the exact count of pending overruns in the
>     same time.
>      >
>      >
>      >
>      > I definitely agree with you here.
>      >
>      > IMHO, there is no point in calling rt_task_wait_period() a few
>      > times in a row just to clean up the "poverrun" counter
>      > (if there were a few overruns) when the whole may be reported at
>     once.
>      > This former way just gives unnecessary overhead.
>      >
> 
>     My concern is that some recovery procedure might require to get the
>     exact number
>     of pending overruns to operate properly in order to catch up with
>     the missing
>     expiries, and there is no way to get this information out of the
>     current API (!).
>     Even calling rt_task_wait_period in loop and testing for -ETIMEDOUT
>     is unusable,
>     since well, we would obviously get blocked when the overrun count
>     drops to zero,
>     which is not what we want in order to be able to run the recovery
>     procedure asap.
> 
> 
> All in all, I would vote for changing the current rt_task_wait_period() 
> interface.

I'm convinced now that this is the way to go too, because the current interface is 
not only limited, but broken, since it does not allow to tell the recovery 
procedure the exact count of pending overruns.

This is a widely used routine unfortunately, so the change won't go unnoticed, but 
on the other hand, v2.1 is likely the last opportunity we have to clean the native 
API from legacy issues, without resorting to using weird hacks aimed at keeping 
the binary and source compatibilities, many of which end up polluting the API they 
are supposed to protect.

>  
> 
> 
>      >
>      > Actually, there is a kind of application that must not rely on
>      > the "poverrun" counter, the klatency/latency utility and alike.
>      >
>      > They are run normally (at least at the very first time) in the
>     untrusted
>      > environment
>      > where SMI or something similar - that may prevent a CPU from
>     handling normal
>      > interrupts for quite a long time - make occur happily.
>      > As the "poeverrun" counting is dependent on the timer interrupt,
>      > it becomes irrelevant.
>      >
>      > Something like
>      > overruns = (real_time_of_wakeup - desired_time_of_wakeup) /
>     period (*)
>      > should be rather used there (of course, the timing source must not be
>      > interrupt-dependent).
> 
>     Ah! you know what, I'm pretty sure that one of your very first
>     public posts on the
>     RTAI/fusion mailing list at that time, was exactely about this issue
>     :o) 
> 
> 
> Good memory indeed; so it's too earlier for you to get retired :o)
>  

"G3" still means "inspired guitar masters" to me, and not some obscure powerpc 
thingy, so I guess that I've not been spoiled by IT yet. Way too early to retire then.

> 
>     --
> 
>     Philippe.
> 
> 
> 
> 
> -- 
> Best regards,
> Dmitry Adamushko


-- 

Philippe.

Re: [Xenomai-help] resume/suspend periodic timing issue

[Philippe Gerum]

Steven Seeger wrote:
> I have never see an RTOS exhibit this behavior,

Perhaps you were not misusing that RTOS?

  and previous versions of
> Fusion

Check the code, it's no novelty.

  and the classic RTAI did not.
> 

Who cares?

> Steven
> 
> 
> On 2/27/06 10:39 AM, "Gilles Chanteperdrix"
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
> 
>>This behaviour is due to the way the overruns are accounted for: not
>>having called rt_task_wait_period while the periodic timer elapses is
>>currently considered an abnormal usage of the interface, and counted as
>>an overrun.
>>
>>A way around this behaviour is to create an alarm object with
>>rt_alarm_create, and use rt_alarm_start and rt_alarm_wait for each
>>shot.
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.