[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