[Xenomai] A fix to few generic issues in rttcp stack
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
>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.
More information about the Xenomai