[Xenomai-help] rt_task_wait_period returns an undocumented value

[Xenomai-help] rt_task_wait_period returns an undocumented value

[Fernando Herrero Carrón]

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

Dear list,

I am running xenomai-2.6-rc4 on an amd64 linux kernel version 2.6.38.8.

I am setting up a periodic task using

rt_task_set_periodic(NULL, TM_NOW, 11500);

For period values smaller than 11450 I get an EINVAL return value. I've got
one question regarding this, and it's how is this threshold calculated?

However, further down the program, supposing rt_task_set_periodic() failed
with the above result, calling

rt_task_wait_period()

will return EAGAIN, which is not documented in
http://www.xenomai.org/documentation/trunk/html/api/group__task.html#ga1645d3a072ef3cefeed3bcbb27dcf108
.

Best regards,
Fernando

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

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Gilles Chanteperdrix]

On 10/21/2011 06:04 PM, Fernando Herrero Carrón wrote:
> Dear list,
> 
> I am running xenomai-2.6-rc4 on an amd64 linux kernel version 2.6.38.8.
> 
> I am setting up a periodic task using
> 
> rt_task_set_periodic(NULL, TM_NOW, 11500);
> 
> For period values smaller than 11450 I get an EINVAL return value. I've got
> one question regarding this, and it's how is this threshold calculated?

See:
http://www.xenomai.org/documentation/trunk/html/api/group__pod.html#gaed5776a428e7c59b52b1da76f0d765fa

> 
> However, further down the program, supposing rt_task_set_periodic() failed
> with the above result, calling
> 
> rt_task_wait_period()
> 
> will return EAGAIN, which is not documented in
> http://www.xenomai.org/documentation/trunk/html/api/group__task.html#ga1645d3a072ef3cefeed3bcbb27dcf108
> .

That is because glibc choose to have EWOULDBLOCK == EAGAIN. And 
EWOULDBLOCK is documented.

-- 
					    Gilles.

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Fernando Herrero Carrón]

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

El 21 de octubre de 2011 14:15, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> escribió:

> On 10/21/2011 06:04 PM, Fernando Herrero Carrón wrote:
> > Dear list,
> >
> > I am running xenomai-2.6-rc4 on an amd64 linux kernel version 2.6.38.8.
> >
> > I am setting up a periodic task using
> >
> > rt_task_set_periodic(NULL, TM_NOW, 11500);
> >
> > For period values smaller than 11450 I get an EINVAL return value. I've
> got
> > one question regarding this, and it's how is this threshold calculated?
>
> See:
>
> http://www.xenomai.org/documentation/trunk/html/api/group__pod.html#gaed5776a428e7c59b52b1da76f0d765fa
>

Hmm, that doesn't make very clear why some values for "period" are accepted
and some others are not. Are they fixed? Are they calculated based on some
system-dependent calibration procedure?


> >
> > However, further down the program, supposing rt_task_set_periodic()
> failed
> > with the above result, calling
> >
> > rt_task_wait_period()
> >
> > will return EAGAIN, which is not documented in
> >
> http://www.xenomai.org/documentation/trunk/html/api/group__task.html#ga1645d3a072ef3cefeed3bcbb27dcf108
> > .
>
> That is because glibc choose to have EWOULDBLOCK == EAGAIN. And
> EWOULDBLOCK is documented.
>
>
Ok, I see. This seems a bit confusing to me. What would happen if someone
were using a different libc than glibc? If the code is using EWOULDBLOCK all
over the place then that's fine.

Finally, what do you think of extending:

-EWOULDBLOCK is returned if
rt_task_set_periodic()<http://www.xenomai.org/documentation/trunk/html/api/group__task.html#gababee94264156693cd4f5b9b70d3c5a1>has
not previously been called for the calling task.

to

-EWOULDBLOCK is returned either if
rt_task_set_periodic()<http://www.xenomai.org/documentation/trunk/html/api/group__task.html#gababee94264156693cd4f5b9b70d3c5a1>has
not previously been called for the calling task, or if a previous call
to that function failed.

Just for the sake of completeness ;)

Fernando

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

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Gilles Chanteperdrix]

On 10/21/2011 07:37 PM, Fernando Herrero Carrón wrote:
> El 21 de octubre de 2011 14:15, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> escribió:
> 
>> On 10/21/2011 06:04 PM, Fernando Herrero Carrón wrote:
>>> Dear list,
>>>
>>> I am running xenomai-2.6-rc4 on an amd64 linux kernel version 2.6.38.8.
>>>
>>> I am setting up a periodic task using
>>>
>>> rt_task_set_periodic(NULL, TM_NOW, 11500);
>>>
>>> For period values smaller than 11450 I get an EINVAL return value. I've
>> got
>>> one question regarding this, and it's how is this threshold calculated?
>>
>> See:
>>
>> http://www.xenomai.org/documentation/trunk/html/api/group__pod.html#gaed5776a428e7c59b52b1da76f0d765fa
>>
> 
> Hmm, that doesn't make very clear why some values for "period" are accepted
> and some others are not. Are they fixed? Are they calculated based on some
> system-dependent calibration procedure?

Summarized version: "-EINVAL is returned if (...) period is different
from TM_INFINITE but shorter than the scheduling latency value for the
target system, as available from /proc/xenomai/latency"

I do not see how it could be made more clear.

> 
> 
>>>
>>> However, further down the program, supposing rt_task_set_periodic()
>> failed
>>> with the above result, calling
>>>
>>> rt_task_wait_period()
>>>
>>> will return EAGAIN, which is not documented in
>>>
>> http://www.xenomai.org/documentation/trunk/html/api/group__task.html#ga1645d3a072ef3cefeed3bcbb27dcf108
>>> .
>>
>> That is because glibc choose to have EWOULDBLOCK == EAGAIN. And
>> EWOULDBLOCK is documented.
>>
>>
> Ok, I see. This seems a bit confusing to me. What would happen if someone
> were using a different libc than glibc? If the code is using EWOULDBLOCK all
> over the place then that's fine.
> 
> Finally, what do you think of extending:

I find the current version perfectly clear and find no reason to extend
it this way. Having called a function which failed should be equivalent
to not having called the function, in any reasonable API.

Not checking services return values, and continuing anyway in case of
error is a bad programming habit, especially when writing "critical" code.

-- 
					    Gilles.

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Fernando Herrero Carrón]

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

El 21 de octubre de 2011 15:47, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> escribió:

> On 10/21/2011 07:37 PM, Fernando Herrero Carrón wrote:
> > El 21 de octubre de 2011 14:15, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> escribió:
> >
> >> On 10/21/2011 06:04 PM, Fernando Herrero Carrón wrote:
> >>> Dear list,
> >>>
> >>> I am running xenomai-2.6-rc4 on an amd64 linux kernel version 2.6.38.8.
> >>>
> >>> I am setting up a periodic task using
> >>>
> >>> rt_task_set_periodic(NULL, TM_NOW, 11500);
> >>>
> >>> For period values smaller than 11450 I get an EINVAL return value. I've
> >> got
> >>> one question regarding this, and it's how is this threshold calculated?
> >>
> >> See:
> >>
> >>
> http://www.xenomai.org/documentation/trunk/html/api/group__pod.html#gaed5776a428e7c59b52b1da76f0d765fa
> >>
> >
> > Hmm, that doesn't make very clear why some values for "period" are
> accepted
> > and some others are not. Are they fixed? Are they calculated based on
> some
> > system-dependent calibration procedure?
>
> Summarized version: "-EINVAL is returned if (...) period is different
> from TM_INFINITE but shorter than the scheduling latency value for the
> target system, as available from /proc/xenomai/latency"
>
> I do not see how it could be made more clear.
>

Alright, excuse me, I missed that explanation.

Then let me move to the actual figures at hand:

 $ cat /proc/xenomai/latency
3349

and, as I explained above, all values below 11450 are being rejected in my
case.



> >
> >
> >>>
> >>> However, further down the program, supposing rt_task_set_periodic()
> >> failed
> >>> with the above result, calling
> >>>
> >>> rt_task_wait_period()
> >>>
> >>> will return EAGAIN, which is not documented in
> >>>
> >>
> http://www.xenomai.org/documentation/trunk/html/api/group__task.html#ga1645d3a072ef3cefeed3bcbb27dcf108
> >>> .
> >>
> >> That is because glibc choose to have EWOULDBLOCK == EAGAIN. And
> >> EWOULDBLOCK is documented.
> >>
> >>
> > Ok, I see. This seems a bit confusing to me. What would happen if someone
> > were using a different libc than glibc? If the code is using EWOULDBLOCK
> all
> > over the place then that's fine.
> >
> > Finally, what do you think of extending:
>
> I find the current version perfectly clear and find no reason to extend
> it this way. Having called a function which failed should be equivalent
> to not having called the function, in any reasonable API.
>

>From the system's perspective this is true. I mean, they should be
equivalent in the sense that the state of the system should be the same
after "not calling" a function and after calling that function and having it
fail.

I disagree from a developer/debugger perspective. When tracing errors that
depend on the execution history of your program, it is not the same to not
call a function than to call it and have a bug in your error correction
code. Because if you have a function failing and you are aware that all the
preconditions for it are met, you will most surely look for the source of
your error somewhere else. If at some point you are pointed to one of those
preconditions not being met, then finding the solution becomes easier. So
considering the programmer's state of mind, I don't feel both situations are
equivalent. I don't mean to be too picky on this one, I just want to explain
my point of view. Especially when it refers to documentation, I believe that
"too much" is never too much.

Not checking services return values, and continuing anyway in case of
> error is a bad programming habit, especially when writing "critical" code.
>

Well, this I know, but as a library designer you should not rely on your
users exhibiting best practices for your library to be correct and complete.
And your piece of advice does in no way preclude you from providing the most
complete documentation possible.

Fernando

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

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Gilles Chanteperdrix]

On 10/21/2011 08:08 PM, Fernando Herrero Carrón wrote:
> Alright, excuse me, I missed that explanation.
> 
> Then let me move to the actual figures at hand:
> 
>  $ cat /proc/xenomai/latency
> 3349
> 
> and, as I explained above, all values below 11450 are being rejected in my
> case.

I guess you have to check the code to understand what happens. But
really, running tasks with a 11500 period is already preposterous.

> my point of view. Especially when it refers to documentation, I believe that
> "too much" is never too much.

Conciseness is really important for a documentation, look at an example,
the sentence explaining the -EINVAL return value for
rt_task_make_periodic was a bit long, and you missed the important part,
even though I had told you that it was where was the answer to your
question. So, too much documentation is a problem, because users will
inevitably miss what is important.

Now look at an example outside Xenomai documentation:
http://pubs.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_lock.html

The documentation for EINVAL says:
[EINVAL]
    The value specified by mutex does not refer to an initialized mutex
object.

It does not say, "or an object for which pthread_mutex_init failed", it
is pretty obvious that if pthread_mutex_init failed, the mutex is not
initialized. period.

-- 
                                                                Gilles.

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Fernando Herrero Carrón]

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

El 21 de octubre de 2011 16:47, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> escribió:

> On 10/21/2011 08:08 PM, Fernando Herrero Carrón wrote:
> > Alright, excuse me, I missed that explanation.
> >
> > Then let me move to the actual figures at hand:
> >
> >  $ cat /proc/xenomai/latency
> > 3349
> >
> > and, as I explained above, all values below 11450 are being rejected in
> my
> > case.
>
> I guess you have to check the code to understand what happens. But
> really, running tasks with a 11500 period is already preposterous.


It's the very minimal example that I could come up with, I can attach the
code if you will. But there is not much more than mlockall(),
rt_task_shadow(), rt_task_set_periodic() and
while(){rt_tast_wait_period()}...

Why do you mean it is preposterous? Because it is not a round figure or
because it is too low? If you mean it is too low, well, I have a DAQ board
that can make acquisitions at up to 120kHz, which means a period of 8000 ns.
I want to achieve the fastest acquistion rate possible, and was pushing the
limits to see where xenomai could go.


> > my point of view. Especially when it refers to documentation, I believe
> that
> > "too much" is never too much.
>
> Conciseness is really important for a documentation, look at an example,
> the sentence explaining the -EINVAL return value for
> rt_task_make_periodic was a bit long, and you missed the important part,
> even though I had told you that it was where was the answer to your
> question. So, too much documentation is a problem, because users will
> inevitably miss what is important.
>
> Now look at an example outside Xenomai documentation:
>
> http://pubs.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_lock.html
>
> The documentation for EINVAL says:
> [EINVAL]
>    The value specified by mutex does not refer to an initialized mutex
> object.
>
> It does not say, "or an object for which pthread_mutex_init failed", it
> is pretty obvious that if pthread_mutex_init failed, the mutex is not
> initialized. period.
>
>
But it also does not say "pthread_mutex_init was not called"... It is
stating a precondition on the state of the program (or process, to be more
precise), not on the calling sequence of functions. Translating this to our
case, we could say "[EINVAL] The task has not been properly configured to
run in periodic mode.", or something like that, which includes both the case
of not calling the configuring function or that function failing.

Anyway, my suggestion was not such a big issue. It is ok for me to leave the
documentation as it is.

Thanks for your attention,
Fernando

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

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Gilles Chanteperdrix]

On 10/21/2011 09:01 PM, Fernando Herrero Carrón wrote:
> El 21 de octubre de 2011 16:47, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> escribió:
> 
>> On 10/21/2011 08:08 PM, Fernando Herrero Carrón wrote:
>>> Alright, excuse me, I missed that explanation.
>>>
>>> Then let me move to the actual figures at hand:
>>>
>>>  $ cat /proc/xenomai/latency
>>> 3349
>>>
>>> and, as I explained above, all values below 11450 are being rejected in
>> my
>>> case.
>>
>> I guess you have to check the code to understand what happens. But
>> really, running tasks with a 11500 period is already preposterous.
> 
> 
> It's the very minimal example that I could come up with, I can attach the
> code if you will. But there is not much more than mlockall(),
> rt_task_shadow(), rt_task_set_periodic() and
> while(){rt_tast_wait_period()}...

I mean check xenomai code.

> 
> Why do you mean it is preposterous? Because it is not a round figure or
> because it is too low? If you mean it is too low, well, I have a DAQ board
> that can make acquisitions at up to 120kHz, which means a period of 8000 ns.
> I want to achieve the fastest acquistion rate possible, and was pushing the
> limits to see where xenomai could go.

Because it is way too low, you will get a complete lockup of your system
as soon as you starting putting load on it.

-- 
                                                                Gilles.

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Fernando Herrero Carrón]

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

El 21 de octubre de 2011 17:07, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> escribió:

> On 10/21/2011 09:01 PM, Fernando Herrero Carrón wrote:
> > El 21 de octubre de 2011 16:47, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> escribió:
> >> I guess you have to check the code to understand what happens. But
> >> really, running tasks with a 11500 period is already preposterous.
> >
> >
> > It's the very minimal example that I could come up with, I can attach the
> > code if you will. But there is not much more than mlockall(),
> > rt_task_shadow(), rt_task_set_periodic() and
> > while(){rt_tast_wait_period()}...
>
> I mean check xenomai code.
>

Oh, yeah, I will.


> >
> > Why do you mean it is preposterous? Because it is not a round figure or
> > because it is too low? If you mean it is too low, well, I have a DAQ
> board
> > that can make acquisitions at up to 120kHz, which means a period of 8000
> ns.
> > I want to achieve the fastest acquistion rate possible, and was pushing
> the
> > limits to see where xenomai could go.
>
> Because it is way too low, you will get a complete lockup of your system
> as soon as you starting putting load on it.
>
>
Ok, thanks for the advice. The computations I will be doing will not be very
expensive in principle, but I believe the analogy infrastructure is the
actual bottleneck. I have not been able to perform the acquisitions I want
beyond 10kHz. At higher frequencies it looks like analogy does not have
enough time to acknowledge all DMA interruptions. But this is a different
issue.

Best regards,
Fernando

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

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Daniele Nicolodi]

On 21/10/11 21:15, Fernando Herrero Carrón wrote:
> Ok, thanks for the advice. The computations I will be doing will not be
> very expensive in principle, but I believe the analogy infrastructure is
> the actual bottleneck. I have not been able to perform the acquisitions
> I want beyond 10kHz. At higher frequencies it looks like analogy does
> not have enough time to acknowledge all DMA interruptions. But this is a
> different issue.

I think you are doing something wrong then (and the fact that you need a
periodic task to perform such acquisitions smells like there is
something wrong in your code). I have acquisitions running at over 200
kHz for weeks without a glitch.

Cheers,
-- 
Daniele

Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Fernando Herrero Carrón]

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

2011/10/21 Daniele Nicolodi <daniele@domain.hid>

> On 21/10/11 21:15, Fernando Herrero Carrón wrote:
> > Ok, thanks for the advice. The computations I will be doing will not be
> > very expensive in principle, but I believe the analogy infrastructure is
> > the actual bottleneck. I have not been able to perform the acquisitions
> > I want beyond 10kHz. At higher frequencies it looks like analogy does
> > not have enough time to acknowledge all DMA interruptions. But this is a
> > different issue.
>
> I think you are doing something wrong then (and the fact that you need a
> periodic task to perform such acquisitions smells like there is
> something wrong in your code). I have acquisitions running at over 200
> kHz for weeks without a glitch.
>
> Cheers,
>
>
Dear Daniele,

I'm glad to hear from you, because I found some posts on the list that
pointed to my same problems.

Actually no, I don't need a periodic task. I was just comparing interrupt
based vs. polling based acquisitions. But my first attempt has always been
using the TRIG_WAKE_EOS flag to setup a command and then use read() in
comedi and then async_read() in analogy to read those values.

I've got one question for you. Do you process each scan separately or are
you working with blocks? 15kHz in comedi and 10kHz with analogy has been the
highest rate I have achieved for end-of-scan processing (reading 8 channels
and writing 8 channels in each iteration of the loop).

I am very interested in your approach, any help is greatly appreciated.

Fernando

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