Re: Limitations with v2 port implementation
S Roderick <[email protected]> Wed, 08 Apr 2015 10:13:09 -0400
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1681535793== Content-type: multipart/alternative; boundary="Apple-Mail=_9229722E-C317-4DCF-B1B5-9B07D07F0A44" --Apple-Mail=_9229722E-C317-4DCF-B1B5-9B07D07F0A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 08, 2015, at 10:09, Herman Bruyninckx = <[email protected]> wrote: > On Wed, 8 Apr 2015, S Roderick wrote: >=20 >> On Apr 08, 2015, at 09:41, Herman Bruyninckx = <[email protected]> wrote: >>=20 >> On Wed, 8 Apr 2015, S Roderick wrote: >>=20 >> On Apr 08, 2015, at 09:25, Ruben Smits = <[email protected]> >> wrote: >>=20 >> 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. >>=20 >> 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 =93flow=94 (i.e. when a = connection object >> was >> updated). >>=20 >> v2 ports have one =93object" per input/output = connection, and >> maintain >> potentially different values and flow status = per connection >> (yes, I=92m >> simplifying here). So one output port connected = to N input >> ports will >> have N connections, each with potentially = different values >> and flow >> status. >>=20 >> We=92ve run into two issues with v2 ports: >>=20 >> 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. >>=20 >> 2) flow status does not cover the use case = where you want a >> single >> connection object, and don=92t care when a = connection is made >> nor when a >> value is written (i.e. you don=92t care about = =93flow=94). One of >> our examples >> here is static configuration data (say the = name, model or >> serial number, >> of a device, or a robot=92s 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 =93flow=94 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=92t >> 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_1C= onnPolicy.htm >> l# >> a5da839ba68d6ff35ddc44171562ed356 and a have a writer with >> keepLastWrittenValue to true. >>=20 >> 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. >=20 > 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). >=20 >> Yes, the two can be used interchangeably, but the removal of the = Event primitive in v2 was a >> huge mistake IMHO. I=92m sure that some of you won=92t agree =85 = shrug. >> =20 >> I don=92t think that that solves the whole issue. You = still have multiple >> connections =3D> >> performance hit. Also, didn=92t we find a thread-safety = issue with that >> approach? >>=20 >> 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=92s one point of view. I still maintain that the Orocos v1 and = v2 do a pretty damn good job >> for what they=92re designed for. >=20 > 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. Disagree Herman. That=92s the same user (not developer) documentation = issue that has plagued Orocos since the beginning. It=92s not the = primitives he=92s struggling with - it=92s a lack of documentation on = how to use the entire framework. But this is off topic. >> Yes, we=92d all like some things done differently, but it=92s still a >> very usable system as is. >=20 > For experts, it's (still) the best! :-) But the same can be achieved > with less effort and code... (Hindsight, you know=85.) YMMV S --Apple-Mail=_9229722E-C317-4DCF-B1B5-9B07D07F0A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Apr = 08, 2015, at 10:09, Herman Bruyninckx <<a = href=3D"mailto:[email protected]">Herman.Bruyninckx@mech.= kuleuven.be</a>> wrote:<br><div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div = style=3D"font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;">On Wed, 8 Apr 2015, S Roderick = wrote:<br><br><blockquote type=3D"cite">On Apr 08, 2015, at 09:41, = Herman Bruyninckx <<a = href=3D"mailto:[email protected]">Herman.Bruyninckx@mech.= kuleuven.be</a>> wrote:<br><br> On Wed, = 8 Apr 2015, S Roderick = wrote:<br><br> = On Apr 08, 2015, at 09:25, Ruben Smits <<a = href=3D"mailto:[email protected]">[email protected]<= /a>><br> &nb= sp;wrote:<br><br> &nb= sp; On Wed, Apr 8, 2015 at 1:08 PM, = S<br> Rod= erick <<a = href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br>&= nbsp; &nb= sp; We have ported = a large Orocos system from v1 to v2, = and<br> i= dentified = some<br> = limitati= ons in the v2 port implementation that we wanted = to<br> di= scuss = with<br> = the = community.<br><br> &n= bsp; &nbs= p;v1 ports essentially had one connection object, and thus = one<br> v= alue. = When<br> = you = connected/read the port, you got the last value that = was<br> w= ritten.<br> &nb= sp; There= was no concept of =93flow=94 (i.e. when a connection = object<br> &nbs= p;was<br>  = ; updated= ).<br><br> &nbs= p; v2 = ports have one =93object" per input/output connection, = and<br> m= aintain<br> &nb= sp; poten= tially different values and flow status per = connection<br> = (yes, = I=92m<br>  = ; simplif= ying here). So one output port connected to N = input<br>  = ;ports = will<br> = have N = connections, each with potentially different = values<br> &nbs= p;and = flow<br> = status.<= br><br> &= nbsp; We=92ve = run into two issues with v2 = ports:<br><br> = 1)= performance when writing to output ports is much slower = in<br> v2= = than<br> = v1, as = essentially the update occurs to multiple = connection<br> = objects = in<br> &n= bsp; v2 (in = v1 it occurred to one connection object). One of = our<br> c= omponents<br> &= nbsp; has= a 450% slow down when writing to its eight (8) = output<br> &nbs= p;ports.<br><br> &nbs= p; = 2) flow status does not cover the use case where you want = a<br> sin= gle<br> &= nbsp; connectio= n object, and don=92t care when a connection is = made<br> = nor when = a<br> &nb= sp; value is = written (i.e. you don=92t care about =93flow=94). One = of<br> ou= r = examples<br> &n= bsp; here= is static configuration data (say the name, model = or<br> se= rial = number,<br> &nb= sp; of = a device, or a robot=92s number of DOF). When the = source<br> &nbs= p;component = is<br> &n= bsp; configured= or started, it writes the appropriate data to = the<br> p= ort. If = a<br> &nb= sp; connection = is made in the future (say by a GUI, or by = a<br> rep= orting<br> &nbs= p; compon= ent that has dynamically created ports) then v2 = ports<br>  = ;will = not<br> &= nbsp; present = the value that was previously written (I believe = as<br> th= ere = has<br> &= nbsp; been no = =93flow=94 of data since the connection was made). = In<br> th= is use = case,<br>  = ; we = believe that the v1 single-connection-object = semantics<br> &= nbsp;made = more<br> = sense = as connected peer components are only interested in = the<br> v= alue, = and<br> &= nbsp; not = when it was written nor whether it has been updated = (i.e.<br>  = ;they = don=92t<br> &nb= sp; care = about = flow).<br> &nbs= p;AFAIK, you can have 2) working in v2 if you create the connection = using<br>  = ;the init flag set<br>totrue: <a = href=3D"http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/class= RTT_1_1ConnPolicy.htm">http://www.orocos.org/stable/documentation/rtt/v2.x= /api/html/classRTT_1_1ConnPolicy.htm</a><br> = l#<br> &n= bsp; a5da839ba68d6ff35ddc44171562ed356 a= nd a have a writer = with<br> = keepLastWrittenValue to true.<br><br> We = made a mistake in the original RTT design by providing too = many<br> configuration options. This is not = a problem if every configuration<br> leads = to a unique feature, but it does become a problem if = different<br> configurations can provide = the same feature. An example is = the<br> "difference" between properties and = attributes, or events and data.<br> So, = while you are probably right, I still think this is not the = Right<br> Way to go.<br>I disagree with = some of this. Properties and attributes are very similar concepts, and = it can be<br>difficult to choose one over the other. But events and data = are quite different for us. Events<br>(to us) are much more a state = machine primitive - Data is stuff you move between = components.<br></blockquote><br>This is a _semantic_ difference, and an = important one. But RTT should<br>have provided only _mechanism_; in the = code, both events and data flows<br>are treated very similar; the only = difference happen to be in the<br>_communication_ policies (e.g., = different ways to throw away messages).<br><br><blockquote = type=3D"cite">Yes, the two can be used interchangeably, but the removal = of the Event primitive in v2 was a<br>huge mistake IMHO. I=92m sure that = some of you won=92t agree =85 = shrug.<br> <br> = I don=92t think that that solves the whole issue. You still = have = multiple<br> &n= bsp;connections = =3D><br> &nb= sp;performance hit. Also, didn=92t we find a thread-safety issue with = that<br> = approach?<br><br> Both problems are = _communication_ related, so should be solved in = the<br> _communication_ middleware... = Select one that is minimal and does = one<br> thing right (ZeroMQ? nanomsg?) and = has an eye for performance. I would<br> now = strip RTT to a pure realtime "container", that is, a = "computation<br> only" version of the Linux = or Solaris containers. Again, trying to = do<br> one thing right.<br>That=92s one = point of view. I still maintain that the Orocos v1 and v2 do a pretty = damn good job<br>for what they=92re designed = for.<br></blockquote><br>Performance wise and configuration wise, I = agree! :-)<br>But too many people are scared away by the lack of clarity = of what of<br>its features to use exactly why and when. A good example = is the ongoing<br>discussion of the new user who wants to connect a GUI = to realtime.<br></div></blockquote><div><br></div>Disagree Herman. = That=92s the same user (not developer) documentation issue that has = plagued Orocos since the beginning. It=92s not the primitives he=92s = struggling with - it=92s a lack of documentation on how to use the = entire framework. But this is off = topic.</div><div><br></div><div><blockquote type=3D"cite"><div = style=3D"font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;"><blockquote type=3D"cite">Yes, we=92d = all like some things done differently, but it=92s still a<br>very usable = system as is.<br></blockquote><br>For experts, it's (still) the best! = :-) But the same can be achieved<br>with less effort and code... = (Hindsight, you = know=85.)<br></div></blockquote><div><br></div>YMMV</div><div>S</div><div>= <br></div></body></html>= --Apple-Mail=_9229722E-C317-4DCF-B1B5-9B07D07F0A44-- --===============1681535793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Orocos-Dev mailing list [email protected] http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev --===============1681535793==--