The problem I see is that you can't assume system A would be faster with timing mechanism X, or system B with timing mechanism Z. This may vary from device to device. I believe this is not something that can be reliably solved without querying the actual system at runtime.
See a) http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-gettimeofday_speedup.html b) http://www.win.tue.nl/~aeb/linux/lk/lk-4.html#ss4.6 yrs, jardel On Thu, Aug 4, 2011 at 4:01 PM, Dave Hart <h...@ntp.org> wrote: > On Thu, Aug 4, 2011 at 18:36 UTC, Nick Mathewson <ni...@freehaven.net> > wrote: > > 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. > > Option 3 seems like the only sane approach to attempting to > heuristically decide whether or not to cache time-of-day. > Configure-time checks could mislead, as the runtime system may have > binary-compatible but very different behavior, such as Linux due to > different underlying timesource selection. > > I'm not sure what you mean about tracking down which versions of what > are fast, though. Can't you simply test the same path libevent will > use to fetch the time? The decision to use CLOCK_MONOTONIC vs. > gettimeofday() could be taken first, then a few queries in a row of > the clock via the selected mechanism and some threshold used to decide > whether to cache or not (perhaps with a way to force the choice, in > case). If the trapping clock reads are 100x slower than the mapped + > TSC approaches, a sane threshold that's reasonably future-proof seems > achievable. > > I'm not volunteering to do this, either, I'm afraid. > > Cheers, > Dave Hart > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. >
