Martin Husemann wrote:
>On Wed, Jul 20, 2005 at 12:15:47PM +0200, Frank Kardel wrote:
>  
>>From what I saw in PHK's timecounter code I was positively impressed.
>>It actually gives an abstraction to cycle counters
>>and knows what their  resolution and quality is.
>>    
>
>How does it differ from the <sys/cc_microtime.h> stuff that we have currently?
>  
Much, just a few topics I spotted:
  - increased precision (up to 2^ -64 secs)
  - all abstractions micro, nano and bin time in precise (counter reading)
    and not so precise
  - readable (AFAICS)  without locks/spls
  - clock tick effect (update) aware - retries when timer interrupt has
struck
  - integrates interaction with ntp_time code

As for cc_microtime.h: This has only the time-keeping variables needed
for a cycle counter. There is no information about quality or an
indirection to a
counter reading function that would be needed to pick up something else
than TSC. TSC is sort of "hard" coded (well configurable via header-files
or a global function. But there is no explicit concept of a generalized
high speed counter.

From FreeBSD's sys/time.h (#ifdef _KERNEL)
/*
 * Functions for looking at our clock: [get]{bin,nano,micro}[up]time()
 *
 * Functions without the "get" prefix returns the best timestamp
 * we can produce in the given format.
 *
 * "bin"   == struct bintime  == seconds + 64 bit fraction of seconds.
 * "nano"  == struct timespec == seconds + nanoseconds.
 * "micro" == struct timeval  == seconds + microseconds.
 *             
 * Functions containing "up" returns time relative to boot and
 * should be used for calculating time intervals.
 *
 * Functions without "up" returns GMT time.
 *
 * Functions with the "get" prefix returns a less precise result
 * much faster than the functions without "get" prefix and should
 * be used where a precision of 10 msec is acceptable or where
 * performance is priority. (NB: "precision", _not_ "resolution" !)
 *
 */

It would also give us nano second capability which AFAICT is not
really there yet.

Frank