Re: Limitations with v2 port implementation

On Wed, 8 Apr 2015, S Roderick wrote:

> On Apr 08, 2015, at 09:25, Ruben Smits <[email protected]> wrote:
>
>       On Wed, Apr 8, 2015 at 1:08 PM, S Roderick <[email protected]> wrote:
>             We have ported a large Orocos system from v1 to v2, and identified some
>             limitations in the v2 port implementation that we wanted to discuss with
>             the community.
>
>             v1 ports essentially had one connection object, and thus one value. When
>             you connected/read the port, you got the last value that was written.
>             There was no concept of “flow” (i.e. when a connection object was
>             updated).
>
>             v2 ports have one “object" per input/output connection, and maintain
>             potentially different values and flow status per connection (yes, I’m
>             simplifying here). So one output port connected to N input ports will
>             have N connections, each with potentially different values and flow
>             status.
>
>             We’ve run into two issues with v2 ports:
>
>             1) performance when writing to output ports is much slower in v2 than
>             v1, as essentially the update occurs to multiple connection objects in
>             v2 (in v1 it occurred to one connection object). One of our components
>             has a 450% slow down when writing to its eight (8) output ports.
>
>             2) flow status does not cover the use case where you want a single
>             connection object, and don’t care when a connection is made nor when a
>             value is written (i.e. you don’t care about “flow”). One of our examples
>             here is static configuration data (say the name, model or serial number,
>             of a device, or a robot’s number of DOF). When the source component is
>             configured or started, it writes the appropriate data to the port. If a
>             connection is made in the future (say by a GUI, or by a reporting
>             component that has dynamically created ports) then v2 ports will not
>             present the value that was previously written (I believe as there has
>             been no “flow” of data since the connection was made). In this use case,
>             we believe that the v1 single-connection-object semantics made more
>             sense as connected peer components are only interested in the value, and
>             not when it was written nor whether it has been updated (i.e. they don’t
>             care about flow).
> 
> 
> AFAIK, you can have 2) working in v2 if you create the connection using the init flag set
> totrue: http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_1ConnPolicy.html#
> a5da839ba68d6ff35ddc44171562ed356 and a have a writer with keepLastWrittenValue to true.

We made a mistake in the original RTT design by providing too many
configuration options. This is not a problem if every configuration
leads to a unique feature, but it does become a problem if different
configurations can provide the same feature. An example is the
"difference" between properties and attributes, or events and data.
So, while you are probably right, I still think this is not the Right
Way to go.

> I don’t think that that solves the whole issue. You still have multiple connections =>
> performance hit. Also, didn’t we find a thread-safety issue with that approach?

Both problems are _communication_ related, so should be solved in the
_communication_ middleware... Select one that is minimal and does one
thing right (ZeroMQ? nanomsg?) and has an eye for performance. I would
now strip RTT to a pure realtime "container", that is, a "computation
only" version of the Linux or Solaris containers. Again, trying to do
one thing right.

(BTW what I describe above is already Work In Progress in our group; for
way too long, because of a lack of development power...)

> S

Herman

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev