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

In message: <20051031102424.V11619_at_fledge.watson.org>
            Robert Watson <rwatson_at_freebsd.org> 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