Date: Sun, 27 Nov 2005 13:23:00 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys time.h src/sys/kern kern_time.c Message-ID: <20051127131838.F81764@fledge.watson.org> In-Reply-To: <20051127234937.X28222@delplex.bde.org> References: <200511270055.jAR0tIkF032480@repoman.freebsd.org> <20051127005622.H81764@fledge.watson.org> <20051127234937.X28222@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Nov 2005, Bruce Evans wrote: > % /* > % * Small wrapper library to substitute implementations of gettimeofday(2) > and > % * time(3) with lower resolution variations. time(3) is unconditionally > % * degraded, since it will return a truncated time anyway. gettimeofday(3) > % * checks the TIMEWRAPPER environmental variable, which can be set to > either > % * "PRECISE" or "FAST". > % */ > > time(3) should use the environment variable too, since the fast version > gives a value that is both imprecise and wrong. It inherits bugs from > the kernel's time_second variable. time_second is not the current time > truncated, but is the (current time less up to about tc_tick/HZ) > truncated. It lags the current time by more than 1 second for up to > about tc_tick/HZ seconds before every rollover of the correct truncated > time. Yes -- this is a mistake in the current library wrapper. All interfaces modified to be "fast" or "precise" should be controlled by the environmental variable so that testing is more consistent (i.e., other than wrapping costs, the non-configured version should behave identically to the non-wrapped version). As mentioned in my previous e-mail, I have no particular commitment to any particular implementation of "fast", but feel that to understand the implications of time measurement costs on applications, we need some way to express this. The POSIX APIs seem to lack any way for an application to express its requirements for time quality vs performance, meaning that if a system errs on the side of quality (FreeBSD), applications will perform much more slowly and potentially no better than on a system which errs on the side of performance (Linux). We work very hard to provide very accurate time stamps for applications that sometimes don't need them, and while uniformly degrading quality doesn't make sense, a bit more expressiveness appears to be required to do better. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051127131838.F81764>