[ntp:questions] Polling interval in FreeBSD vs. Windows

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Wed Jan 19 14:45:05 UTC 2011


Dave Hart wrote:
> On Tue, Jan 18, 2011 at 19:18 PM, unruh<unruh at wormhole.physics.ubc.ca>  wrote:
>> On 2011-01-18, David Woolley<david at ex.djwhome.demon.invalid>  wrote:
>>> wander, and you set a very fast poll, you could get low offsets but a
>>> high error, because the real error is in the wander. Â Increasing the
>>
>> No. a fast poll also corrects wander faster. ntpd is horribly slow at
>> correcting wander, but doing it quickly corrects it faster.
>
> I would agree if you said "perceived wander with measurement-induced
> error".  In other words, while turning the slew knob faster reduces
> your offsets faster, doing so risks following measurement noise rather
> than the underlying trend.
>
>> What it does
>> not do  is to give a good estimate of wander. The drift correction flops
>> around much more with faster polls, because of the short baseline. That
>> does not matter if you have constant connectivity, but becomes important
>> if you loose connectivity for any time period.
>
> It matters to me.  I want my frequency slewing to ignore measurement
> noise, not react quickly to it.
>
>>> This may be complicated in that I'm not sure that the loop time constant
>>> is actually clamped by the poll rate, so it is possible that setting a
>>> high rate over samples without changing the overall behaviour. Â Maybe it
>>> is clamped by maxpoll?
>>
>> No, it is determined by the number of readings, not by time. More
>> readings in a given time means shorter time constant. Fewer readeings,
>> longer. ntpd throws away 7 out of 8 readings, so the actual poll
>> interval of used reading is 8 times as long as the set poll interval,
>> and the time constant is about 5 times that if I remember correctly.
>
> You do not understand NTP's clock filter.  As each new sample is
> pushed in, only one of the prior 8 samples is used for the moment, but
> each sample has 8 chances to be that favorite.  That is not equivalent
> to "throwing away 7 out of 8 readings" on my planet.

There's also the fact that for refclocks ntpd will measure/save the PPS 
signal that arrives every second, a larger poll interval just means that 
there are more samples to choose from.

I.e. with minpoll 4 my Oncore or Garmin refclocks will deliver 16 
samples into the core engine for every poll period.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"




More information about the questions mailing list