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

Subject: Re: [Boost-users] [asio] async udp socket latency
From: Steven Clark (steven.clark_at_[hidden])
Date: 2015-07-02 11:16:28

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]> 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