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

["Dmitry Adamushko" <dmitry.adamushko@domain.hid>]

[-- 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 --]