Hi,

Alan Barrett wrote:

>On Fri, 09 Jun 2006, Frank Kardel wrote:
>
>>Resolution options:
>>   - Find a way to detect whether TSC frequency follows cpu
>>     frequency if yes: no TSC for timekeeping as default that platform
>>   - no TSC as default when powermanagement is present
>>   - use other more suitable time counters (e. g. ACPI timer)
>>
>
>If you had a log of the history of recent CPU speed changes (with old
>speed, new speed, and timestamp for each change) then it should be
>possible to do the right arithmetic.  Add a hook to the timecounters
>framework so that the speedstep code can report "I am now changing the
>speed from X to Y", and let the timecounters code do the bookkeeping.
>
>--apb (Alan Barrett)
>
>
This is a usable idea. A few remarks to that.
    - we need to keep a consistent time scale
    - the time spent in the call to change the speed is completely unknown
      and may depend on the actual implementation in the chipsets
    => we would need to switch to a fixed frequency counter for the
      time of the switch. Currently timecounters are not
      attributed for variable/fixed frequency. so it is currently
      har to find a fixed frequency counter for transition.
    - the sequence to switch/update the frequency of TSC could be
      * select fixed frequency counter
      * change frequency
      * update TSC frequency
      * select TSC again

Now, there have been proposals to look into other systems solutions.
I have looked into FreeBSD during the port and it just ignores TSC
when this risk exists and selects other counters (e.g. i8254). FreeBSD
does not even attempt to make TSC available in MP configurations.
I have not checked others.

What would be gain if we would solve the frequency issue for TSC?
I think very little.
Why ?
Systems switching cpu frequency often are usually not interested in sub
microsecond time stamps. This is especially true as the whole powersaving
stunts will lead to a wide range of temperature variations. Temperature
affects the oscillator frequencies. So the increased resolution of the
counter is offset by the loss in frequency stability. Additionally the
effectively usable resolution of TSC is limited as we still have a
long syscall path until we get to the counter (no user level reading for
now - see projects page for that task). So the time it takes to get a time
stamp shadows much of the benefits of the high frequency counter. To
get an imperession of the effectively user level accessible resolution
of TSC see the precision line at ntpd startup (/var/log/messages). Or look
at 'ntpq -c "rc 0 precision"'. 2^precision is the effective resolution
when reading the clock from user level. (user level counter reading anyone?)
Given the above limitations and effects a lower frequency counters like
the ACPI timer is just as good for those power saving environments.

I think we would currently gain more benefit in supporting (fixed frequency)
ACPI counters and other counters first.

At this time converting ports, adding more counters and picking useful
defaults are the things that would have my priority.

best regards,
  Frank