Date: Mon, 31 Oct 2005 12:03:48 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Robert Watson <rwatson@FreeBSD.org> Cc: Alexander Leidinger <Alexander@Leidinger.net>, freebsd-current@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?) Message-ID: <81484.1130756628@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 31 Oct 2005 10:33:04 GMT." <20051031102424.V11619@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Provided we are ok with clock_gettime(CLOCK_REALTIME) and time(3) not agreeing at all times, then I have no objections to this one. >- Leave clock_gettime(2) as-is, since applications making use of this > clock are likely looking for high resolution. Here we have to be more specific, we could add more CLOCK_FOO values without affecting the existing. CLOCK_REALTIME and CLOCK_MONOTONIC should return precise results IMO. >- I'm not sure what to do about gettimeofday(). My leaning is to look at > lowering the quality to improve performance. An entirely different take on this is to make it a per-process (per-thread ?) option if timestamps are precise or not. We'd just need to give the processes a bit to flip to state their preference. This makes for far smaller patches to applications than anything which adds new timescales or functions. >- Add an interface for extracting high resolution time data, such as the > Solaris interface, and start migrating applications that care to that > interface. No opinion yet, I havn't studied the solaris 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. Ok, let me get one thing very clear: As long as we are talking timestamps out of the timecounter code, there is by design and definition only one piece of hardware that controls. To change that would require somebody to dump a couple of months into the code. If we are talking timestamps in the sense of calling rdtsc(), then it is an entirely different matter. >- Investigate the quality offered by various other systems. One of the > claims made is that we offer better time keeping than Linux systems, It's more that we default to known safe configs where Linux takes a more "it worked for me" attitude to their hardware selection. If somebody with access to the necessary docs (ie: Intel + AMD NDAs) writes a piece of code that can tell us if using the TSC is safe, then we can also use the TSC in those cases. But lacking that function, enabling the TSC by default when so many machines has trouble with it would be counter to our normal attitude to system stability. > 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?). Just because Linux doesn't see major problems in timekeeping doesn't really guarantee that their timekeeping isn't causing major problems. Problems originating in timekeeping tend to be classified as heisenbugs because they are hard to reproduce. As recently as a couple of weeks ago, I saw how a commercial UNIX make a dent in a project plan because the kernel jumped a few milliseconds when a lot of text scrolled by in an Xterm. You get to guess how many weird theories they had tried out before I nailed that diagnosis. Another thing to remember is that the TSC and ACPI hardware is not the only thing we have to deal with: Any solution we implement needs to also work on other architectures, including i486 with only i8254 timecounters etc. And finally, WinTel know that the ACPI timer sucks, thats why more recent hardware has HPET timers, I'm working on support for that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81484.1130756628>