Daniel Carosone wrote:

>On Fri, Jun 23, 2006 at 09:11:33AM +0200, Frank Kardel wrote:
>  
>
>>microtime() with timecounters is nice as it already uses up to
>>then available high resolution counters. but nanotime or bintime
>>would even be better when high resolution counters have been
>>registered and selected at the point.
>>    
>>
>
>My initial guess was that getnanotime() was probably what was wanted,
>then trying to understand the difference between the get* and plain
>variants led me on the manpage search discussed elsewhere.
>  
>
true. get*time is quick an coarse as it uses a cached value
and avoids accessing  any hardware. It is good for places
that traditionally accessed the struct  timeval  {mono_}time  structure.
It can also be used where resolution is not at premium.
the non-get versions try the best for maximum available precision.
for rnd -stuff I this you'd like these better.

>I'd also like to better understand some of the boundary conditions
>early in boot: how soon is it safe/sensible to call timecounters,
>
right from start - though what you get differs over the initialization 
process.

> what
>do i get if no sources have been registered yet,
>
the dummy counter. counts up at at least one between each non-get *time
call. claimed frequency is 1Mhz IIR :-).

> etc.  Note that for
>this usage, I don't necessarily care ifI get back a time of 0 (or
>whatever), as long as I don't cause a panic as microtime apparently
>can on some platforms.
>  
>
not a problem here. so depending how far you are in the initialization 
process
you get increasingly better estimates starting with an invocation 
counter that
is rapidly replaced with platform specific fixed frequency counters.

>>>
>>>
>>>      
>>>
>>they are only changed if they seem better by quality or frequency
>>(@same quality).
>>    
>>
>
>What I meant was that the time sample when the counter is detected,
>and the sample when the default is changed immediately after, are
>probably going to differ by a ~constant amount each boot, if at all -
>so doing both of the above isn't worthwhile.
>  
>
I would then say we either feed when selecting the new counter and
use the counter value at registration when it didn't make the selection.
So we can make use of counter values for all registrations and when
switching. This primariy supports the boot process.
Should we consider feeding counter deltas(!) between clock interrupts into
rnd ?

>--
>Dan.
>  
>
Frank