On 29.07.2012 15:26, Bruce Evans wrote:
On Sun, 29 Jul 2012, Alexander Motin wrote:

On 29.07.2012 11:37, Bruce Evans wrote:
...
binuptime() is more accurate than uncalibrated scaling.  Is accuracy
required?

Accuracy is not required at all. +-20% is not a problem.

If not, the CPU ticker might work, and is faster than HPET,
and and is not under user control for perverse settings.  It normally
reduces to readtsc() with no serializing instruction even in proposed
changes.  This is good enough for process times (not very good) and
depends on the CPU not changing.  Its calibration is very accurate
(similar to timecounters) modulo bugs, but not always up to date.

Problem with ticker that it may stop during idle periods, and idle is
exactly what happens here. Unlike timecounter usage here we don't need
CPU synchronicity, but we need it working during deep sleeps.

The ticker is the same as the timecounter in many cases of interest.  If
the TSC stops then it cannot be used for timecounting unless timecounting
is reinitialized.  Timecounting should be reinitialized after deep sleeps,
but you say you need it to work during deep sleeps.

Timecounter already has detection logic to disable TSC in cases where it is unreliable. I don't want to replicate it here. I need not precise and not synchronized by reliable and fast time source.

I wouldn't trust timecounters for some time after waking up after a
deep sleep.  If their clock stopped then the times read might only be
very out of date.  If their clock didn't stop, then they might have
wrapped or otherwise overflowed and the times read would be garbage.
Is there any locking or ordering to prevent them being used before they
are reinitialized?

I am not sure what reinitialization are you talking about. IIRC, there is no any waking up code for TSC. None other time counters have problems with C-states.

--
Alexander Motin
_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to