Date: Sat, 29 Oct 2005 01:01:59 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Pertti Kosunen <pertti.kosunen@pp.nic.fi>, David Xu <davidxu@freebsd.org>, "Yuriy N. Shkandybin" <jura@networks.ru>, current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 Message-ID: <20051029005719.I20147@fledge.watson.org> In-Reply-To: <35696.1130538037@critter.freebsd.dk> References: <35696.1130538037@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Oct 2005, Poul-Henning Kamp wrote: > The alternative is the degrade the quality of the standard timescales: > clock_gettime(CLOCK_REALTIME), time(2) and gettimeofday(). > > The question there is: are we willing to live with the fallout ? Another important question is whether using these alternative time access methods in user space improves the performance of any of the applications we care about. Hence providing a patch that someone can try -- while the microbenchmarks seem to show improved performance, will the applications? I suspect it will in some important cases, but there's only one way to find out. It strikes me that replacing time(3) with something that retrieves CLOCK_SECOND shouldn't harm time(3) semantics. Likewise, keeping CLOCK_REALTIME as is is likely OK -- if an application requests it using clock_gettime(), then it is presumably looking for high accuracy. It's gettimeofday() that's the troubling one -- it's widely used to query the time in applications, and its API suggests microsecond resolution. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051029005719.I20147>