Re: [Xenomai-help] [RT_PIPE] - User space read() not waking up

[Viktor STARK <abraar@domain.hid>]

Dmitry Adamushko wrote:
>
> Hello,
>  
>
>     I wrote a RT kernel module for a DAQ card. The DAQ card gets
>     interrupts every 200 us (5 kHz) and I've got a RT interrupt
>     handler which wakes up a RT function
>
>
> I guess, you mean a RT task. Is it a kernel or user space task?
>  
It's a kernel space RT task, yes.
>
>     [...]
>     So basically, my question is:
>     If I have rt_pipe_write() writing to a pipe from a kernel module
>     with a 200 us period and I have a read() in a tight loop reading
>     from that same pipe is user space, what could be the origin of the
>     fact that sometimes my read() doesn't get woken up?
>
>
> Xenomai does provide a Linux system with hard real-time support but it 
> doesn't make the Linux kernel itself hard real-time, nor user-space 
> applications which relies merely on the standard kernel services.
>
> Your task (here it even doesn't matter whether it's a linux or xenomai 
> task) relies on read() so it's under control of the linux scheduler, 
> hence it depends on the /scheduling latency/ provided by Linux, not 
> Xenomai.
>
> Roughly speaking, with Xenomai you have 2 domains: primary (all 
> time-critical activities must stay here) and secondary (Linux standard 
> drivers, applications, xenomai tasks while executing linux system calls).
>
> So hard real-time support is provided only as long as your 
> tasks/drivers work in the primary domain. To this goal, (1) drivers 
> are developed with RTDM (preferable way); (2) applications (both 
> kernel and user-space) are developed using one of the Xenomai skins 
> (native, posix, ...).
>
> And as I mentioned above, it's not a case for your task with a read() 
> loop.
>
> So you should probably reconsider your application design to clearly 
> separate the parts that require hard real-time support from the rest.
I do understand the domain separation, but if I got things right, pipes 
can only be read using read() in user space. That's also what the API 
documentation suggests.

Of course, a read() can be scheduled by Linux, but:
1) Why does it happen exactly every 10000 cycles (2 seconds)? The fact 
that this erratic behaviour is so deterministic makes me think that it 
might not be standard Linux related. I mean the fact that it happens 
every 2 seconds (and I mean 2e6 us, not just approximately 2 seconds) 
just makes it look like it's provoked by something which is RT.
2) Even if my read() is scheduled, how comes I only get past the read() 
after the second rt_pipe_write()? One would think that if my read() is 
scheduled I could be waking up after 250 us or 300 us, no? But I'm 
*always* woken up after 2 cycles (that is 400 us).
3) Pipes seemed to be a good way to transfer data from kernel space. 
What other (maybe more deterministic) way would you suggest? I'm not 
asking for a complete program architecture here just a half dozen words 
describing how you would have done it.

Thanks for your help.

Best regards,

Viktor STARK
>
>
> -- 
> Best regards,
> Dmitry Adamushko