[Xenomai] A fix to few generic issues in rttcp stack

Matti Suominen matti.suominen at wapice.com
Fri Apr 1 11:36:26 CEST 2016


From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix at xenomai.org] 
Sent: 31. maaliskuuta 2016 19:23
To: Matti Suominen <matti.suominen at wapice.com>
Cc: Lassi Niemistö <lassi.niemisto at wapice.com>; xenomai at xenomai.org
>> TCP is disabled in Xenomai 3 rtnet. The main problem is that creating 
>> a socket in Xenomai 3 requires switching to secondary mode, so the 
>> "accept" service seems hard to implement without leaving primary mode. 
>> Given the fact that TCP can not be a deterministic protocol, I planned 
>> to drop TCP support in the next RTnet iteration.
>> If you require to send messages over TCP from a thread running in 
>> primary mode, you should rather pass the message using an XDDP socket 
>> to a thread running in secondary mode and using plain linux TCP 
>> sockets. You will not get more determinism with TCP in RTnet.
>
>The question I guess, is, why do you need rttcp ? If you really need it, 
>then we will have to find a solution for the "accept" problem.
>Keeping a pool of sockets ready for instance.
>

Sorry to hear that you are planning to drop support for rttcp. It's a 
useful feature. TCP can be used by deterministic way if your connection is 
point to point and thus retransmission is clearly a sign for error in  
connection. Rttcp is also significantly faster than regular tcp.

For demonstration, I ran some test in a setup with rttcp client and two 
server implementations; one rttcp and one with regular sockets. Our tests 
are showing that average round-trip-time for same server application is 
half when using rttcp instead of normal Linux sockets (470 µs vs. 960 µs). 
Maximum rtt in our case is 4 ms for rt and easily over 10 ms for normal 
Linux sockets. Each send/recv call with regular sockets drops to secondary 
mode so there is no way the rtt maximum could be deterministic. Dropping 
does not happen in rttcp.

In many applications it isn't a problem when accept drops to secondary 
mode, because creating a connection surely doesn't need to be a real time 
operation when connection serving is still real time. Of course accept 
which drops to secondary mode is kind a blemish when you think a big 
picture of real time kernel, but definitely isn't a reason to drop rttcp 
away.

>From my point of view it is clearly useful feature if same application 
(for example Modbus/TCP) can be used from rt and pc clients, and I thus do 
not need to maintain two protocols.

Matti



More information about the Xenomai mailing list