Re: Limitations with v2 port implementation

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.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 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. 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. Yes, we’d all like some things done differently, but it’s still a very usable system as is.

YMMV
S

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