[ntp:questions] Re: NTP clients not throttling back is this behaviour RFC compliant?
hack
hack at watson.ibm.com
Thu Dec 4 23:40:04 UTC 2003
In article <x7llpuntx0.fsf at capsicum.wsrcc.com>,
Wolfgang S. Rupprecht <wolfgang+gnus20031203T010359 at dailyplanet.dontspam.wsrcc.com> wrote:
>
>Terje Mathisen <terje.mathisen at hda.hydro.com> writes:
>> Novell's Netware had a fast path for 'File Read' requests that could
>> take an incoming packet, parse it, verify the file handle, access
>> rights etc, locate the data somewhere in cache, construct a reply
>> packet, and hand that off to the network card again in just
>>
>> 300 cycles
>
>Interesting!
>
>> I.e. the timestamps would be handled with a user-level library
>> function that uses the normal "extrapolate from the last timer tick
>> using RDTSC or similar" approach.
>
>My first thought was to keep the TSC counts corresponding to the last
>few PPS crossings around in an array in the kernel. One would also
>keep a seconds since the epoch counter that got incremented once per
>second by the same PPS signal.
>
>Now that one has the past history of the TSC crossings one can lightly
>filter it and generate tics-per-second. This would only have to be
>done once per second. One would then multiply the TCS tics since the
>last PPS crossing by the tics_per_second to get the fractional seconds
>for the timestamp. What does that come out to? One multiply and
>addition for the timestamp?
>
>-wolfgang
>--
>Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
I agree -- and I don't understand why modern systems still care about timer
ticks. Timer ticks may be useful for time slicing and other dispatching
matters when the machine has no CPU timer of clock comparator -- but it
seems a woefully complicated and inadequate way to keep time, if (as in
most current machines) there is some high-resolution counter available.
A linear interpolation of the TSC can give correct and stable time to
within a fraction of 1 ppm, and the interpolation parameters can be
updated periodically (by reference to an external time source) to keep
the offset bounded. Compared to this, NTP-driven Unix time seems to
jump around a lot -- but that's because NTP's assumption seems to be
that the local oscillator is the least-quality clock source, when in
fact it may be the best (in the short term, at least). (Interpolation
parameters should of course be updated so as not to introduce any step
discontinuities -- assuming of course that the initial offset is good.
So the problem boils down primarily to one of clock initialisation.)
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.
Michel.
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?
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.)
More information about the questions
mailing list