Re: [Libevent-users] Strange timeout scheduling in 1.4

[Nicholas Marriott <nicholas.marriott@xxxxxxxxx>]

AFAIK this optimization in Linux is only available on some architectures
and there is a knob with several possible settings.

Without this, gettimeofday() can be quite expensive.


On Wed, Jul 27, 2011 at 01:10:05PM -0700, William Ahern wrote:
> 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 majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.