Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Nov 2005 08:59:48 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        rwatson@FreeBSD.org
Cc:        phk@phk.freebsd.dk, freebsd-current@FreeBSD.org
Subject:   Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?)
Message-ID:  <20051101.085948.112718728.imp@bsdimp.com>
In-Reply-To: <20051101080018.R18382@fledge.watson.org>
References:  <81213.1130754398@critter.freebsd.dk> <20051031.215329.115777034.imp@bsdimp.com> <20051101080018.R18382@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20051101080018.R18382@fledge.watson.org>
            Robert Watson <rwatson@FreeBSD.org> writes:
: On Mon, 31 Oct 2005, M. Warner Losh wrote:
: 
: > In message: <81213.1130754398@critter.freebsd.dk>
: >            "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: > : I am going to insist that clock_gettime(CLOCK_REALTIME, CLOCK_UPTIME)
: > : remain precise.
: >
: > 1ms is way too imprecise for the stuff we do at work.  We need 3-4 more 
: > orders of magnitude at a minimum from the time keeping system. Ideally, 
: > through well documented interfaces.
: 
: While I agree that for many consumers, sub-1ms accuracy is too low, I 
: suggest that as a vendor of atomic clocks, your company is in fact not the 
: average consumer of timing information. :-).

For the atomic clocks, we use much better hardware to get timing.  The
requirements for better than 1ms time keeping comes from the process
control aspects of our code, not measuring atomic clocks.

: One nice thing about the Linux TSC model, despite its limitations, is that 
: it provides a middle ground between incrementing the clock in ticks and 
: providing a more continuous measure of time, by allowing interpolation 
: between ticks.

That's a non-sequitor to what I'm talking about.. :-)

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051101.085948.112718728.imp>