From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 00:02:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3767116A41F; Sat, 29 Oct 2005 00:02:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDD0643D46; Sat, 29 Oct 2005 00:02:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A26C546B06; Fri, 28 Oct 2005 20:01:59 -0400 (EDT) Date: Sat, 29 Oct 2005 01:01:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <35696.1130538037@critter.freebsd.dk> Message-ID: <20051029005719.I20147@fledge.watson.org> References: <35696.1130538037@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Pertti Kosunen , David Xu , "Yuriy N. Shkandybin" , current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2005 00:02:01 -0000 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