On Thu, Jul 28, 2011 at 3:35 AM, Nicholas Marriott <nicholas.marri...@gmail.com> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
