> > The gettimeofday() time does not need to be higher resoloution than about
> > 10ms 
> 
> BZZZT!  Sorry, Terry, but you've once again forgotten about NTP.  Read
> Dave Mills' article in a recent (or forthcoming?) issue of CCR to find
> out how to use NTP to get better than 500us accuracy, given a kernel
> design which is not inimical to Mills' technique.
> 

I think this is confusing the update frequency of the clock location used
by gettimeofday() (which is the reporting resoloution) and the *ACTUAL*
frequency of the clock that the clock location used by gettimeofday() is
updated *from*.  The two do not need to be identical was my point.

The network time protocol daemon needs to operate on a real clock, but
the update frequency of the time reported in the gettimeofday() report
need not be in excess of whaever the process quantum is.

Sun has a real update frequency of 10ms, with a delta time added to the
report based on an actual clock fetch of a delta clock (that is itself
reset on each update of the updated clock location, every 10ms).

Solaris (SVR4) uses this same mechanism, but unfortuantely does not deal
correctly with the delta reporting (neither does UnixWare).  If you want
to be critical, this is acceptable for SVID, but the concomitant loss
of resoloution in get/setitimer is in violation of SVID (ie: SVR4 does
not conform to SVID).  8-).


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

------------------------------------------------------------------------------