Re: [Boost-users] [asio] async udp socket latency

Subject: Re: [Boost-users] [asio] async udp socket latency
From: Andrew Hundt (athundt_at_[hidden])
Date: 2015-07-02 14:32:52

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 <steven.clark_at_[hidden]> 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 <s_sourceforge_at_[hidden]
> <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_at_[hidden] <javascript:;>
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- 
Cheers!
Andrew Hundt