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

[Leonid Evdokimov <leon@xxxxxxxxxxxx>]

On Wed, Jul 27, 2011 at 22:49, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> 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.

Nick, thanks! That was exactly another pair of eyes I was looking for!
I added relative delta between cached value (well, something really
close to it) and current time to the timeout and it improves situation
a bit, though, with higher number of timeouts (e.g. 64k), the
difference between real cached value and approximated cached value
strikes again.

I tried to emulate EV_TIMEOUT|EV_PERSIST events to have precise
periodic scheduler, so I tried libevent2

> 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.

Yes, I know that, that was the first thing I checked. 1ms is good
enough for me at the moment, the real pain was unpredictable timeout
bias.

I tried to use EV_TIMEOUT|EV_PERSIST as simulation of internal "cron
daemon" that runs callback every X ms and found out, that it works
exactly as I expect: it never schedules timeout before it should be
scheduled.
I tested usage of EVENT_BASE_FLAG_NO_CACHE_TIME and it did not matter
much. Probably the reason is that I don't manually reschedule timeout
anymore.

Also, FYI, I tried to use event_base_init_common_timeout with trivial
timeout callback and got following numbers:

18% of single CPU core usage with 65536 250ms persistent timeouts
7% of single CPU core usage with 65536 250ms persistent common-timeouts

So common timeouts are really nice and, moreover, trivial to use.

--
WBRBW, Leonid Evdokimov
xmpp:leon@xxxxxxxxxxxx && http://darkk.net.ru
tel:+79816800702 && tel:+79050965222
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.