[ntp:questions] Re: NTP clients not throttling back is this behaviour RFC compliant?

Terje Mathisen terje.mathisen at hda.hydro.com
Fri Dec 5 07:30:02 UTC 2003


hack wrote:
> Of course, if you want to use your system's gettimeofday() routine,
> you suffer it's problems, and NTP may well do the best it can to keep
> that beast close enough to "true" time.

I think that what we're discussing/hoping for, is to replace the core of 
those gettimeofday() os/library calls, to the point where they are in 
fact just a MUL/SHIFT/ADD combination.

At well less han 50 cycles you could do nearly a 100 of them in a single us.

  > P.S.  I am aware of problems with non-uniform cycle counters, e.g. on
>       mobile platforms with power-saving clock speed changes.  In that
>       case one may have to fall back on an external clock, and if that
>       clock only has coarse resolution, regular timer ticks may well be
>       all that's left to measure time.  Perhaps the power management
>       subsystem could manage the time interpolation parameters to deal
>       with this?

Definitely the best approach for ultimate accurace, since the point 
where the frequency changes has to be well known. It will of course be 
neccessary to synchronize those events with an update of the clock 
calculation parameters.

A simple approach which would also handle the normal update sequences 
would be to have two alternating sets of parameters, with a single 
global pointer that selects which is current:

Calculate the proper parameters for the next interval, reset the 
frequency, and update the pointer.
> 
>       Then there are MP systems with multiple cycle counters... and
>       perhaps no way to know which interpolation to apply.  Ouch --
>       unless the maintenance of the interpolation parameters is well
>       integrated into the OS, so that what is visible to a process is
>       always right.  (This could also deal with speed-step changes.)

All x86 SMP machines have a shared 3 MHz counter inside the ACPI (?) 
chipset which _could_ be used, but at a severe loss in precision 
compared to a 300 MHz to 3 GHz cpu counter.

Dave Mill's approach of a separate set of adjustment values per cpu 
would even handle the case where those cpus were running at different 
frequencies, and yes, I have heard about people doing that by accident 
(even under Windows!) and have it work. (I.e. the OS worked, not a 
distributed low-overhead timing facility! WinNT is _really_ bad at 
reporting the current time. :-()

Terje
-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list