Re: Limitations with v2 port implementation

On Wed, 8 Apr 2015, S Roderick wrote:

> On Apr 08, 2015, at 09:41, Herman Bruyninckx <[email protected]> wrote:
>
>       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.htm
>             l#
>             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 disagree with some of this. Properties and attributes are very similar concepts, and it can be
> difficult to choose one over the other. But events and data are quite different for us. Events
> (to us) are much more a state machine primitive - Data is stuff you move between components.

This is a _semantic_ difference, and an important one. But RTT should
have provided only _mechanism_; in the code, both events and data flows
are treated very similar; the only difference happen to be in the
_communication_ policies (e.g., different ways to throw away messages).

> Yes, the two can be used interchangeably, but the removal of the Event primitive in v2 was a
> huge mistake IMHO. I’m sure that some of you won’t agree … shrug.
>  
>             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.
> 
> That’s one point of view. I still maintain that the Orocos v1 and v2 do a pretty damn good job
> for what they’re designed for.

Performance wise and configuration wise, I agree! :-)
But too many people are scared away by the lack of clarity of what of
its features to use exactly why and when. A good example is the ongoing
discussion of the new user who wants to connect a GUI to realtime.

> Yes, we’d all like some things done differently, but it’s still a
> very usable system as is.

For experts, it's (still) the best! :-) But the same can be achieved
with less effort and code... (Hindsight, you know....)

> YMMV
> S

Herman

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