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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Wed, Jul 27, 2011 at 11:24 AM, Leonid Evdokimov <leon@xxxxxxxxxxxx> wrote:
> Hello all,
>
> I assumed, that timeout is never(!) scheduled a-bit-earlier than
> requested and today I see, that either my assumption is wrong, or I
> became a bit insane while writing the code.
>
> I attached simple test for the assertion. For example, I've got
> following strange results:
>
> $ ./event-timeout
> Diff: -1333 us (-1333956 ns) during 4424-th fired event.
>
> $ ./event-timeout
> Diff: -567 us (-568056 ns) during 8676-th fired event.
>
> I run 2.6.38-10-generic x86_64 with libevent 1.4.13-stable-1 from
> Ubuntu 11.04 (natty) and epoll backend on Intel(R) Core(TM) i7-2620M
> CPU @ 2.70GHz CPU.
>
> I build the test-case like that:
> $ gcc event-timeout.c -o event-timeout -levent
>
> I get same result with -O2 compilation flag.
>
> Am I missing some sort of race-condition in my code? Is it bug in
> libevent or expected behavior?

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.

Best of luck,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.