From owner-freebsd-current@FreeBSD.ORG Mon Oct 31 10:18:35 2005 Return-Path: X-Original-To: freebsd-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 2AB6016A422; Mon, 31 Oct 2005 10:18:35 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E111B43D48; Mon, 31 Oct 2005 10:18:34 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9VAIWS0004169; Mon, 31 Oct 2005 10:18:33 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4365EF7B.1020706@freebsd.org> Date: Mon, 31 Oct 2005 18:18:35 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <30595.1130493297@critter.freebsd.dk> <20051028153457.d0wqgn2ask4sgw4k@netchild.homeip.net> <20051029195703.GB39253@dragon.NUXI.org> <43646AAC.2080107@freebsd.org> <20051030093718.GE39253@dragon.NUXI.org> <4364D90F.3090205@samsco.org> <20051031075843.GF39253@dragon.NUXI.org> <20051031083447.Y11619@fledge.watson.org> In-Reply-To: <20051031083447.Y11619@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?) 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: Mon, 31 Oct 2005 10:18:35 -0000 Robert Watson wrote: > > > It has been suggested that the former can operate quite well with > significantly reduced quality. It has alos been suggested that most > applications could operate fine with somewhat reduced quality, but that > the API definitions don't say anything about how to specify application > quality requirements vs performance requirements for time measurement. Can we change gettimeofday and clock_gettime to lower resolution now? I think 1000hz/s is enough for most applications, since a thread can never sleep shorter than a tick for years. We can introduce hrtime_t clock_gethrtime(clockid_t clock) to get hi-resolution time as the one seen in RTLinux, or gethrtime() as seen in Solaris (Daniel Eischen said?) David Xu