Date: Mon, 31 Oct 2005 10:33:04 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: Alexander Leidinger <Alexander@Leidinger.net>, freebsd-current@freebsd.org Subject: Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?) Message-ID: <20051031102424.V11619@fledge.watson.org> In-Reply-To: <4365EF7B.1020706@freebsd.org> 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> <4365EF7B.1020706@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Oct 2005, David Xu wrote: > 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?) Not being a time person, I may be misrepresenting matters, but we do need to be a bit careful: while Linux relies on a lower quality time source (TSC), it continues to offer a high resolution without lots of stepping. I don't understand the issues well enough to reason about how these two compare from a time consumer perspective, but we need to be a little careful not to select the wrong way to lower quality, as that will needlessly hurt applications. And in the case of things like network protocols implemented in user space, I think the fear is real: by reducing the accuracy of (for example) network round trip time measurements, a significant performance impact can result due to miscalculating available bandwidth, timing out lost packets, etc. So far, my leaning has been: - 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. - Leave clock_gettime(2) as-is, since applications making use of this clock are likely looking for high resolution. - I'm not sure what to do about gettimeofday(). My leaning is to look at lowering the quality to improve performance. - Add an interface for extracting high resolution time data, such as the Solaris interface, and start migrating applications that care to that interface. - 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. - 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?). 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. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051031102424.V11619>