On Wed, Jul 27, 2011 at 02:49:26PM -0400, Nick Mathewson wrote: <snip> > So because I'm at a conference this week, I can't examine the code too > closely. But my guess is that this is happening because Libevent > caches its calls to gettimeofday()/clock_gettime() during its event > loop, so that your event is being scheduled relative to the time when > epoll returned, not quite relative to the time when event_add() is > called. > > In Libevent 2.0, you can override this behavior with the > EVENT_BASE_FLAG_NO_CACHE_TIME flag. This will result in more needless > system calls, but more precise timing. > > If you're running on Linux and you're interested in precise timings, > you should also be aware that the time resolution of epoll() is only > one ms. I'd like for Libevent 2.1 to add timerfd support to the epoll > backend, but I don't have a patch for that right now.
Has anyone tested the performance gain of caching? Linux's gettimeofday() doesn't trap into the kernel; it effectively just reads a shared memory page. IIRC it's something like 100x-1000x faster than gettimeofday() in OpenBSD, which (again, IIRC) reads from the hardware clock every call (Linux usually has an HPET update the clock asynchronously). After I did those measurements I quit pursuing a caching strategy in my own code. (I don't use OpenBSD for it's performance.) Maybe the default setting could be different on different platforms, or the default inverted so caching must be requested. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
