[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On Thu, Jul 28, 2011 at 3:35 AM, Nicholas Marriott
<nicholas.marriott@xxxxxxxxx> wrote:
> Interesting.
>
> We have seen problems in the past with gettimeofday() not being very
> deterministic on Linux, with occasional spikes in the time it takes,
> although I don't have the numbers to hand (50-100 microseconds or so are
> the numbers I remember offhand).
>
> If this is to be used as a basis for what libevent should do, I think it
> is worth bearing in mind that as well as varying support on different
> architectures, people may be using older hardware (without, for example,
> invariant TSC) or older kernels (RHEL 5.3, for example, has 2.6.18).
>
> I'm not surprised OpenBSD is much slower though for this though.


Hmmm. So as near as I can tell, coming out of this whole discussion, I
can see a few options for Libevent 2.1:

* Make no changes in the code, but suggest to people that they should
be using EVENT_BASE_FLAG_NO_CACHE_TIME if they are running on a
platform where time checking is very quick and they care about very
accurate timing.

* Do a slightly inaccurate guess about what operating system types
we're on, and always disable time cacheing on places like Linux/OSX.
This will create problems like Nicholas mentions above.

* Probe somehow (probably at runtime) to determine whether we're
someplace that has fast time checking or not.

Option 1 requires no code changes; option 2 is easy; option 3 will
mean more work tracking down which versions of what are fast, and
figuring out how to probe correctly, and is more work than I know if I
can do personally on this.

Thoughts? Volunteers? ;)

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