Christof Meerwald@blog.www

> blog
>> 749

translate to German (by SYSTRAN)

Weblog RDF feed, Atom feed

[previous] / [up] [overview] [down] / [next]

Sun Apr 22 19:18:47 2012 GMT: Design and Analysis of Algorithms I

Sat Apr 21 19:24:24 2012 GMT: boost asio thread contention

Sat Apr 21 14:51:42 2012 GMT: Spurious EPOLLOUT events

One thing I noticed when looking at epoll scalability was that Linux seems to generate lots of spurious EPOLLOUT events (even when using EPOLLET - edge-triggered). To illustrate the issue, have a look at eptest-out.cc. This clearly shows that Linux generates an EPOLLOUT event for each send syscall even though there is no need as the state hasn't changed.

BTW, the strace output also clearly shows those events:

sendto(4, "\7\0\0\0", 4, 0, NULL, 0)    = 4
epoll_wait(3, {{EPOLLOUT, {u32=4, u64=4}}, {EPOLLIN|EPOLLOUT, {u32=5, u64=5}}}, 16, 4294967295) = 2
recvfrom(5, "\7\0\0\0", 4096, 0, NULL, NULL) = 4
recvfrom(5, 0x7fffa14e1000, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
sendto(4, "\10\0\0\0", 4, 0, NULL, 0)   = 4
epoll_wait(3, {{EPOLLOUT, {u32=4, u64=4}}, {EPOLLIN|EPOLLOUT, {u32=5, u64=5}}}, 16, 4294967295) = 2
recvfrom(5, "\10\0\0\0", 4096, 0, NULL, NULL) = 4
recvfrom(5, 0x7fffa14e1000, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)

Note that in this case the EPOLLOUT event on the sending socket always coincides with an EPOLLIN|EPOLLOUT event on the receiving socket, so you don't get an extra wakeup, but you aren't always that lucky...

Sun Apr 01 11:03:28 2012 GMT: Run, Christof, Run

Just couldn't stop running this morning and ended up doing 7 laps around Battersea Park - Google Maps reckons it's about 3.3 km per lap - which would mean around 23 km in total.

Thu Mar 29 20:43:00 2012 GMT: boost asio 1.46.1 vs. boost asio 1.49.0

I have now re-run my socket communication tests with Boost 1.49.0 which shows a huge improvement in the 16 socketpairs case where we actually have some real concurrency:

But the 1 socketpair case still shows some rather bad performance when using multiple worker threads:

Stay tuned...

Tue Mar 27 18:19:40 2012 GMT: Opera 11.62

Well, this release fixes a security issue I reported about 3 months ago...

Sun Mar 25 00:31:10 2012 GMT: Overhead and Scalability of I/O Strategies

Having briefly looked at epoll vs. kqueue on Linux and FreeBSD/NetBSD, I'll now focus a bit more on Linux and this time I am adding some real concurrency into the mix in the hope of seeing some speedup with multiple threads.

The basic test set-up is similar to what we had previously: sending 4-byte datagram packets between a socketpair - but this time we also want to introduce some concurrency and use 16 socketpairs in a second test. And as a test machine we are using a quad-core Intel i7-2600K @ 3.4 Ghz (with hyperthreading enabled - so we get 8 hardware threads).

So in a first test we compare the performance of a blocking send/recv loop, a hand-written epoll loop, boost asio (1.46) and my own async abstraction when changing the number of worker threads (NB: for the blocking send/recv we always use a fixed number of threads equal to the number of socketpairs).

As expected, a blocking send/recv is the fastest option. But what's really interesting to see is that while epoll/asyncsrv only show a moderate slowdown with more worker threads, boost asio shows a significant slowdown. Note that there is only one message in transit, so we wouldn't expect a speedup anyway.

Ok, so let's add some concurrency by increasing the number of socketpairs to 16 (and decreasing the number of iterations accordingly).

Now we can see that both the hand-written epoll loop and my async library scale reasonably well and provide a speed-up when the number of worker threads is increased. But boost asio again shows a significant slowdown.

Sat Mar 24 23:28:16 2012 GMT: Romeo and Juliet @ Royal Opera House

Wed Mar 21 22:08:09 2012 GMT: kevent on FreeBSD (Update)

Sun Mar 18 20:55:50 2012 GMT: Multi-threaded epoll/kqueue

Mon Mar 05 23:17:44 2012 GMT: The Dream / Song of the Earth @ Royal Opera House

Fri Mar 02 23:00:37 2012 GMT: DNSSEC fully enabled for cmeerw.net


This Web page is licensed under the Creative Commons Attribution - NonCommercial - Share Alike License. Any use is subject to the Privacy Policy.

Revision: 1.14, cmeerw.org/blog/749.html
Last modified: Mon Sep 03 18:25:50 2018
Christof Meerwald <cmeerw@cmeerw.org>
XMPP: cmeerw@cmeerw.org