meyerj
commented
6 years ago As output Ports are not buffered, all new data is dropped until the data was completely written to the connected input ports.
That's only partially true. For remote connections Orocos adds a local buffer per remote connection for output ports and the write calls never block on Corba. For buffer connections this additional local buffer can also hold multiple elements and unless this buffer is full, no samples will be lost. A Corba dispatcher thread (one per component) is then emptying the local buffer. Unless one-way writes are enabled (compile time option since #123) the dispatcher writes one sample at a time and indeed waits for the remote end to acknowledge, which, for low-bandwidth or high-latency connections could result in dropped samples in the output buffer. But local connections should not be affected by that.
Did you actually observe something different?
planthaber
doudou
Hi,
I'm writing this to have a visible documentation on the issue, the initial explanation including code to reproduce the issue was in a closed PR: https://github.com/orocos-toolchain/rtt/pull/122, which was not a proper solution and raised other issues.
As output Ports are not buffered, all new data is dropped until the data was completely written to the connected input ports.
When a output port has two connections, new writes are only sent when the previous data was sent and the acks were received by corba. This is an issue on remote connections, especially on networks with low bandwidth.
When the low bandwith connection needs longer for the corba ack as the period of the Task, the next message will not be delivered at all. This means not even on the local connection received the message.
So if you connect a remote gui via network, local messages could possibly be lost.
Nevertheless, a simple workaround is to avoid using additional remote connections on output ports, this can be simply achieved by adding a repeater task, which just writes a data type received by an input port to an output port of the same type. This way only the repeater task is losing messages, not the important task with the double connections (original connection + repeater).