Re: Limitations with v2 port implementation

On Apr 08, 2015, at 14:07, Sylvain Joyeux <[email protected]> wrote:

>> - multiple outputs to one input, where the outputs can be switched betwe=
en on the fly. And some of the outputs are synch. while some are asynch. He=
re, flow status is just nasty, and we=92ve had to add a bunch of explicit c=
lear calls, and the like, into our system to effectively flush (or similar)=
 all data when certain mode switches occur. Because the upstream components=
 are coordinated, we only want the last value written (which is, by definit=
ion, from the last component executed)
> =

> Basically, this is broken because samples are not gathered per-port,
> but per-channel. Which means that RTT v2 ports don't have a concept of
> "last value written to the port", only "last value written to the
> channel". Which is something most people "ignore" because the issue
> happens only during the transition (so it is most of the time "hidden"
> when the ports have high data rates). It is an interesting issue. It
> arises as soon as one wants to do RT-compatible switching (where
> disconnecting and reconnecting Syskit-style is not possible) in a
> clean way.

What is =93broken=94 here Sylvain? It isn=92t clear what you mean.

> I personally think that it could make sense to go for a per-input-port
> buffer element, but then a bunch of other configuration problems occur
> (as e.g. you need to size the buffers to accomodate any configuration,
> not only the configuration you have right now, plus it gets weird when
> pulling is involved)
> =

>> - performance - some of our systems run really close to deadline, and th=
e extra few % of updating multiple connection objects is too much.
> I would really like to investigate the performance issue there
> further, but I really don't have time for that.

Fair enough. Neither do we in reality. But I think we can probably agree th=
at the fundamental difference between 8 output ports updating 8 connection =
objects (ala v1), vs 8 output ports updating 40 connection objects (ala v2)=
 (I=92d guess that we=92re 5-to-1 or similar in this case) is always going =
to be worse performance wise.

>> In reality, we=92ve now in v2 got a lot more coupling of the inside of o=
ur components with other peer components, because v2 ports (in *some* ways)=
 require that the end user be more aware of when and whom wrote data.
> While I don't dispute that it is your experience migrating from v1, I
> really personally did not see that so far in systems I was involved
> with. And I am very very careful about keeping components insulated
> (i.e. not putting any system concerns in the component implementation)

Different, not better or worse. :-)

> Anyways, to summarize my understanding of the problems you highlight
> with v2 ports:
> - multiple output, single input connections, in architectures where
> the output components are begin "switched" (i.e. there's only one
> active at a time), and where the input only wants the last value (not
> all values written). In v2, values are read out-of-order. In effect, a
> 'data' connection in v2 becomes an out-of-order buffer where each
> channel has one slot in the buffer.
> - performance

That seems like a pretty good summary of my off-the-top-of-my-head list of =
use cases.
S

-- =

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