Jan Holtz via Xenomai <[email protected]> writes:
> Hello, > > i am running a xenomai 3 on a SMP cobalt kernel using the alchemy skin. > > I have a rt task running in a 10kHz period which has to transfer every > 40ms a amount of data (30.000 byte) to the linux domain task. > > At moment i am using a rt_pipe with the file backend on linux side. > In my setup the rt_pipe_write call takes upto 60 microseconds . > Measured using rt_timer_read. > > I expected that writing to the pipe is the bottleneck, so i created a > second task and used a queue to push data to this task, which is > feeding the pipe. > The runtime for the rt_queue_write is like the same, which i measured > bevore using the rt_pipe_write. > > My questions: > Is the amout of time i need for this action expectable, or may i have > another issue? > Is there a more effective way to communicate/stream data to the linux > task? Are the xddp sockets faster on the xenomai side (i iam correct > the pipe is based on this?) > > > Hope you have s suggestion or a tip. > rt_pipe is based on xddp, which involves a user->kernel->user data roundtrip via Cobalt's xnpipe mechanism, this is likely what is time consuming for the most part. Using xddp should not give you better figures. rt_queue_write may be costly because it first allocates a buffer to write your data to, before queuing it. The allocation + copy ops are likely the outstanding ones in the benchmark figures. If the implementation allows this, you may want to pre-allocate a number of queue buffers using rt_queue_alloc, pushing them to the receiver by calling rt_queue_send. That would mimic rt_queue_write, but moving out the buffer allocation to a non time-sensitive place. You would simply have to manage a free list of pre-allocated buffers. Based on the previous optimization, you may want to prep your data in place, directly into a pre-allocated buffer if possible. That would save you one data copy. -- Philippe.
