On Wed, Jul 27, 2011 at 11:24 AM, Leonid Evdokimov <l...@darkk.net.ru> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
