From owner-freebsd-current@FreeBSD.ORG Tue Nov 1 05:13:27 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 4F79016A421; Tue, 1 Nov 2005 05:13:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 653B343D6D; Tue, 1 Nov 2005 05:13:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA15AOIo011334; Mon, 31 Oct 2005 22:10:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 31 Oct 2005 22:10:35 -0700 (MST) Message-Id: <20051031.221035.122314541.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <20051031102424.V11619@fledge.watson.org> References: <20051031083447.Y11619@fledge.watson.org> <4365EF7B.1020706@freebsd.org> <20051031102424.V11619@fledge.watson.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 31 Oct 2005 22:10:24 -0700 (MST) Cc: 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: Tue, 01 Nov 2005 05:13:27 -0000 In message: <20051031102424.V11619@fledge.watson.org> Robert Watson writes: : - Modify time(3) so that it relies on a timer-driven clock, since it needs : to provide only one second granularity. Applications using second : granularity are probably not all that concerned with high resolution : timing. It also needs to tick close to top of second. That is, it should tick 'soon' (< 1-3/hz) after gettimeofday/clock_gettime does. : - Leave clock_gettime(2) as-is, since applications making use of this : clock are likely looking for high resolution. Some of the calls we have use this itnerface. : - I'm not sure what to do about gettimeofday(). My leaning is to look at : lowering the quality to improve performance. Others use this interface. There's really no indication in the documentation which one provides better time. These two interfaces need to produce coherent timestamps between them, I think. Since many applications are a mix of third party libraries, those libraries will likely make different decisions about which API to use based on the whim of the developer and other intangible concerns. : - Add an interface for extracting high resolution time data, such as the : Solaris interface, and start migrating applications that care to that : interface. clock_gettime() remaining as it like is fine. : - Further investigate the TSC issue. For example, allowing multiple : time counters to be used depending on the API. Right now, all APIs : source from the same timecounter, but you could imagine gettimeofday() : using the TSC (with synchronization added?), and having clock_gettime() : continue to use the higher quality source. I think this is the thrust : of the Solaris approach -- allow direct access to timecounters of : varying quality. "The man with two wrist watches never knows what time it is." Be very careful here, since you need things to produce coherent results between the different methods of getting time. Synchronizing multiple clocks can be tricky. You cannot use TSC with power saving since it changes frequencies at times unknown to you to any real degree of accuracy. The bigger the frequency change, the larger the error you'll have using TSC. Likewise if there are steps in TSC due to other conditions, as has been reported, there's another source of error. : - Investigate the quality offered by various other systems. One of the : claims made is that we offer better time keeping than Linux systems, : which sounds like a nice feature. If all systems offer low quality time : sources for the POSIX APIs, then applications will be written to that : assumption, meaning that offering high quality time there doesn't : necessarily help them (does this follow?). It all depends on what you are trying to do with time. Most applications tolerate errors of 1ms or even 10ms without batting an eye. A minority care a great deal about errors in the us range. : Something to watch out for: while the default HZ is now 1000, it's easy to : imagine HZ being different in different environments. There's been talk : of revisiting the 1000HZ decision to lower overhead, for example, on SMP : systems. We should be careful not to lock ourselves into a high HZ at : this point. If HZ became 100, I think we'd be less happy with : clock_gettime() returning the result of that method of time keeping, even : though time(3) would be fine. We run HZ=1000 at work, except for slow systems that don't have to have low serial port latency. Those we run at HZ=100. I recently ran a AMD 586 (486 class machine at 133MHz) with -current. It was horrible at HZ=1000, but decent at HZ=100. Warner