Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Oct 2005 11:26:38 +0100
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        David Xu <davidxu@freebsd.org>
Cc:        Alexander Leidinger <Alexander@Leidinger.net>, freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org>
Subject:   Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?) 
Message-ID:  <81213.1130754398@critter.freebsd.dk>
In-Reply-To: Your message of "Mon, 31 Oct 2005 18:18:35 %2B0800." <4365EF7B.1020706@freebsd.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <4365EF7B.1020706@freebsd.org>, David Xu writes:
>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 can live with gettimeofday(2) and time(3) being degraded.

I am going to insist that clock_gettime(CLOCK_REALTIME, CLOCK_UPTIME)
remain precise.

>I think 1000hz/s is enough for most applications, since a thread can
>never sleep shorter than a tick for years.

(Famous last words!)

Time is not just a matter of sleeping.

>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?)

You know ? 

This is just a great example of why people feel the autocrap tools
is the way to write portable code :-(

The open group specifically allow clock_gettime() to implement
more timescales, so what did those fools go and invent even more
library functions for ?

Poul-Henning

-- 
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?81213.1130754398>