[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