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

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