Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?)

In message <20051031102424.V11619_at_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_at_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.