Perry E. Metzger wrote:

>Frank Kardel <kardel@netbsd.org> writes:
>  
>
>>>That's not true. I really would like to be able to use cycle counters
>>>for time on my laptop for a number of reasons, including to be able to
>>>deal with multimedia applications better and better timestamps for
>>>profiling purposes.
>>>      
>>>
>>Yes I understand that motivation, but the system can only do a limited
>>number of gettimeofday() calls.
>>    
>>
>
>Who said anything about system calls -- some of the stuff one wants to
>do in the kernel needs to have a good idea of the time.
>
>  
>
It is certainly faster in the kernel (no news here).
I am wondering in what kind of time you are actually interested. Are you
interested in a time related to UTC? Are you interested in a time with
a frequency controlled to be close to the norm (SI second). Or are you
interested in measuring just time differences. I am asking because
I wonder in what time scale you are interested. Depending on the
scale needed different abstrations come to mind: {micro,nano,bin}time
for UTC related timestamping (e.g. event logging). {micro,nano,bin}uptime
for the SI_SECOND related time scale (delta t). Some kind of raw counter
where the frequency is known to manage system relative time relationships.
The effort needed to create the respective abstractions differs:
    counter timestamp: machine instruction
    norm frequency related time: counter * scaling (+ calibration 
infrastructure)
    UTC related time: nor frequency related time + offset.

Maybe we should consider adding a fast unsynchronized time abstraction
for raw counter samples that can be scaled later to favor fast light weight
time stamping (syscall-, user-, system-, trap- and interrupt-time  
measurement
come immediately to mind here).

>>>>Given the above limitations and effects a lower frequency counters like
>>>>the ACPI timer is just as good for those power saving environments.
>>>>        
>>>>
>>>How good is the ACPI timer?
>>>
>>>      
>>>
>>Runs at 3579545 Hz - counter ticks in ~279.4 ns
>>    
>>
>
>Well, as a fallback, that's at least a lot better than the ancient PC
>timer chip. How hard would it be to make that work correctly?
>
>  
>
Thats work in progress - Matthias Drochner already sent me a preliminary 
implementation.

>Perry
>  
>
Frank