Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Your latency will vary, but it will be far from the best you can get. Here are few things that will stand in your way to the better latency:</p> <p><strong>Boost.ASIO</strong></p> <ol> <li>It constantly allocates/deallocates memory to store "state" in order to invoke a callback function associated with your read operation.</li> <li>It does unnecessary <code>mutex</code> locking/unlocking in order to support a broken mix of async and sync approaches.</li> <li>The worst, it constantly adds and removes event descriptors from the underlying notification mechanism.</li> </ol> <p>All in all, <code>asio</code> is a good library for high-level application developers, but it comes with a big price tag and a lot of CPU cycle eating gremlins. Another alternative is <code>libevent</code>, it is a lot better, but still aims to support many notification mechanisms and be platform-independent. Nothing can beat native mechanisms, i.e. <code>epoll</code>.</p> <p><strong>Other things</strong></p> <ol> <li>UDP stack. It doesn't do a very good job for latency sensitive applications. One of the most popular solutions is OpenOnload. It by-passes the stack and works directly with your NIC.</li> <li>Scheduler. By default, scheduler is optimized for throughput and not latency. You will have to tweak and tune your OS in order to make it latency oriented. Linux, for example, has a lot of "rt" patches for that purpose.</li> <li>Watch out not to sleep. Once your process is sleeping, you will never get a good wakeup latency compared to constantly burning CPU and waiting for a packet to arrive.</li> <li>Interference with other IRQs, processes etc.</li> </ol> <p>I cannot tell you exact numbers, but assuming that you won't be getting a lot of traffic, using Boost and a regular Linux kernel, with a regular hardware, your latency will range somewhere between ~50 microseconds to ~100 milliseconds. It will improve a bit as you get more data, and after some point start dropping, and will always be ranging. I'd say that if you are OK with those numbers, don't bother optimizing.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload