Re: Limitations with v2 port implementation
S Roderick <[email protected]> Wed, 08 Apr 2015 15:00:37 -0400
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1950948922== Content-type: multipart/alternative; boundary="Apple-Mail=_4D1F2841-9E80-47EB-B99B-BD2FC5643CF6" --Apple-Mail=_4D1F2841-9E80-47EB-B99B-BD2FC5643CF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 08, 2015, at 14:47, Sylvain Joyeux <[email protected]> = wrote: > 2015-04-08 15:17 GMT-03:00 S Roderick <[email protected]>: >> On Apr 08, 2015, at 14:07, Sylvain Joyeux <[email protected]> = wrote: >>=20 >>>> - multiple outputs to one input, where the outputs can be switched = between on the fly. And some of the outputs are synch. while some are = asynch. Here, flow status is just nasty, and we=92ve had to add a bunch = of explicit clear 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 definition, from the last component executed) >>>=20 >>> 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. >>=20 >> What is =93broken=94 here Sylvain? It isn=92t clear what you mean. >=20 > I meant: your system (which, I agree, is architectured in a valid way) > is broken by migrating to v2 ports. Yep! We got it to work, but it was *much* harder than anyone expected. >> Fair enough. Neither do we in reality. But I think we can probably = agree that 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. >=20 > Yes. Except that it is my opinion that reading and writing to ports > should be low-overhead enough that you would not notice. Unless you > have MB-sized structures, or very very low processing power that is. > There's a lot of overhead in connections, currently, that should not > be there (like a fuckload of mutexes). Moreover, I personally suspect > that the port performance grows faster than linear when the number of > connections grow (from some really really bad performance I got when > creating a lot of connections to a single port). Never benchmarked, > but that's a hunch I have. Those 8 ports we measured total maybe 50 doubles. We=92re actually only = talking 10=92s of microseconds of difference, so not big numbers. But we = have a *lot* of ports (remember, few struct's due v1 toolkits!) and even = that ~4x difference may add up. Actually, our simplest system = configuration has ~700 connections between ports, so maybe 200 to 300 = actual ports ... Cheers S --Apple-Mail=_4D1F2841-9E80-47EB-B99B-BD2FC5643CF6 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 14:47, Sylvain Joyeux <<a = href=3D"mailto:[email protected]">[email protected]</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;">2015-04-08 15:17 GMT-03:00 S = Roderick <<a = href=3D"mailto:[email protected]">[email protected]</a>>:<br><blockquote = type=3D"cite">On Apr 08, 2015, at 14:07, Sylvain Joyeux <<a = href=3D"mailto:[email protected]">[email protected]</a>> = wrote:<br><br><blockquote type=3D"cite"><blockquote type=3D"cite">- = multiple outputs to one input, where the outputs can be switched between = on the fly. And some of the outputs are synch. while some are asynch. = Here, flow status is just nasty, and we=92ve had to add a bunch of = explicit clear 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 definition, from the last component = executed)<br></blockquote><br>Basically, this is broken because samples = are not gathered per-port,<br>but per-channel. Which means that RTT v2 = ports don't have a concept of<br>"last value written to the port", only = "last value written to the<br>channel". Which is something most people = "ignore" because the issue<br>happens only during the transition (so it = is most of the time "hidden"<br>when the ports have high data rates). It = is an interesting issue. It<br>arises as soon as one wants to do = RT-compatible switching (where<br>disconnecting and reconnecting = Syskit-style is not possible) in a<br>clean = way.<br></blockquote><br>What is =93broken=94 here Sylvain? It isn=92t = clear what you mean.<br></blockquote><br>I meant: your system (which, I = agree, is architectured in a valid way)<br>is broken by migrating to v2 = ports.<br></div></blockquote><div><br></div>Yep! We got it to work, but = it was *much* harder than anyone expected.</div><div><br><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">Fair = enough. Neither do we in reality. But I think we can probably agree that = 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.<br></blockquote><br>Yes. Except that = it is my opinion that reading and writing to ports<br>should be = low-overhead enough that you would not notice. Unless you<br>have = MB-sized structures, or very very low processing power that = is.<br>There's a lot of overhead in connections, currently, that should = not<br>be there (like a fuckload of mutexes). Moreover, I personally = suspect<br>that the port performance grows faster than linear when the = number of<br>connections grow (from some really really bad performance I = got when<br>creating a lot of connections to a single port). Never = benchmarked,<br>but that's a hunch I = have.<br></div></blockquote><div><br></div>Those 8 ports we measured = total maybe 50 doubles. We=92re actually only talking 10=92s of = microseconds of difference, so not big numbers. But we have a *lot* of = ports (remember, few struct's due v1 toolkits!) and even that ~4x = difference may add up. Actually, our simplest system configuration has = ~700 connections between ports, so maybe 200 to 300 actual ports = ...</div><div></div><br><div>Cheers</div><div>S</div><div><br></div></body= ></html>= --Apple-Mail=_4D1F2841-9E80-47EB-B99B-BD2FC5643CF6-- --===============1950948922== 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 --===============1950948922==--