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

[Nir Soffer <nirsof@xxxxxxxxx>]

On Aug 4, 2011, at 9:36 PM, Nick Mathewson wrote:

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

This will give the best value for the work needed.

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

This will be very hard to do now, and will be impossible to maintain  
as systems change.

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

This sounds like the best option, a system that choose the best path  
on the current runtime, but may be tricky and time consuming.

Anyone profiled a *real* system and can show that gettimeofday cost is  
significant?




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