On Wed, Jul 27, 2011 at 22:49, Nick Mathewson <ni...@freehaven.net> 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:l...@darkk.net.ru && http://darkk.net.ru tel:+79816800702 && tel:+79050965222 *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
