Blocking socket performance vs. non-blocking socket

Question

I need to write a C++ program to receive udp packets from 2 different NIC at high rate - about 45MB/s per socket (single socket per NIC on the same computer).

I started by creating an event-based socket (using WSAEventSelect) but I'm wondering: does this type of socket model (event-based) may imply some performane penalty ? (since events will be triggered at a high rate and therfore OS may cause some latency) If I choose blocking socket will I reduce latency ? Is it true to say that at high throughput blocking sockets may outperform non-blocking sockets ?

Note: Scalability is not an issue since we deal with no more than two sockets.

Thanks,

AC

Answer 1

If you have only two sockets, why wouldn't you use blocking calls? They have slightly less overhead than any asynchronous socket API and have a simpler programming model. Blocking sockets use async IO under the covers, but they block in the Windows kernel on an event.

You should probably spin up CpuCount/2 reader threads per socket. Although less threads will perform better if they are able to handle the load (depends on your app). Fewer threads means having a small cache footprint and less context switching.

If you care about cross-socket load-balancing a lot you should probably use IO Completion Ports which are the standard and best-performing way on Windows to perform async IO.

What about latency? Blocking calls will have almost the same latency as "event-based" sockets in your case because there are multiple threads per socket waiting in line on an event to accept the next packet that the NIC receives. With a callback-based async IO approach the latency increases slightly. I expect the difference to be very minimal. The kernel does not introduce any latency. It does not wait for clock interrupts to unblock threads for example. Unblocking happens immediately.