Right now I have to still up to a grand total of three devices. However it is for robot so latency is critical. Considering what everyone mentioned, I guess I'll just try out the synchronous version first and stick with that. On Thursday, July 2, 2015, Steven Clark wrote:

Niall is very thorough and careful, but your answer this time skipped a step.

...

On Jul 2, 2015, at 6:28 AM, Niall Douglas javascript:;> wrote: ... I would also add that it is well known that async i/o attracts a ~15% latency over sync i/o. If you want absolute max performance, you create a thread per socket, and let the kernel schedule you more efficiently. However creating thousands of kernel threads is unwise on 32 bit platforms, and comes with substantial demands on perfect...

There are plenty of challenging and valuable applications that use sockets and yet do not need to deal with thousands of connections. The missing step is “If you want absolute max performance -- and your application actually has to scale to thousands of sockets -- …”

I’ve had to deal with some really bad design and implementation by kids who’ve been taught that async i/o is “better”, without bothering to mention the circumstances under which it is and is not better. It’s a hidden assumption that there are no applications but internet server applications. The astute reader might surmise that I’ve suffered enough pain over this issue that it’s become a hot button for me.

Andrew, you mentioned that you're talking to a physical device; that suggests that you may well not need to scale up to thousands of sockets. (For example if the network connects components within a large machine or the devices are on a LAN.) In that case your solution is to use thread-per-socket. Not only will it perform better, it’ll be easier to debug and maintain. The fact that your test program works but the async program is buggy supports this point.

OK, I’ll get off my soapbox and go back into my cave…

Steve Clark

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org javascript:; http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Cheers! Andrew Hundt

On Thu, Jul 2, 2015 at 6:18 PM, Andrew Hundt wrote:

On Thu, Jul 2, 2015 at 5:00 PM, Jonathan Franklin < franklin.jonathan@gmail.com> wrote:

...

On Thu, Jul 2, 2015 at 12:12 AM, Andrew Hundt wrote:

...

runs again? It is 10ms on a number of platforms, which may cause you grief if you're trying to do something (asynchronously) more frequently than that, i.e. 5 ms.

Very interesting! Thread priority could explain it since the async calls yield when they are done and the sync would be returned by the underlying system call at the right time. Thanks!

Interestingly enabling realtime mode with `thread_policy_set()` didn't fix the problem, and actually increased the variation. I'm sure I could pick parameters that would reduce variation, but I don't think it would solve the 8ms problem. mean = 8.000 [ms], std = 0.176, max/min = 17.615/0.059; 6999 iter. Cheers! Andrew Hundt