Hi all,

in nptd, I wonder whether the huffpuff filter generates its own probes
or relies on the (offset, delay) couples already available from the
normal activity of ntpd (like for example the 8 samples visible from
ntpq using "rv <association ID>" ).

it is not clear to me even trying to figure it out from the source code
(seen 900 s sample rate... but I'm not sure to understand what all this
is about).

Regards,
Edrusb

On 13/11/16 21:51, Edrusb wrote:
>
> in nptd, I wonder whether the huffpuff filter generates its own probes
> or relies on the (offset, delay) couples already available from the
> normal activity of ntpd (like for example the 8 samples visible from
> ntpq using "rv <association ID>" ).

It doesn't produce its own probes; that would be pointless.

It looks like it uses the minimum over the last two and a quarter hours, 
give or take fence post effects, with a resolution of 15 minutes.

>
> it is not clear to me even trying to figure it out from the source code
> (seen 900 s sample rate... but I'm not sure to understand what all this
> is about).

What problem are you really trying to solve?

Le 14/11/2016 à 11:25, David Woolley a écrit :
> On 13/11/16 21:51, Edrusb wrote:
>>
>> in nptd, I wonder whether the huffpuff filter generates its own probes
>> or relies on the (offset, delay) couples already available from the
>> normal activity of ntpd (like for example the 8 samples visible from
>> ntpq using "rv <association ID>" ).
> 
> It doesn't produce its own probes; that would be pointless.

Thanks for clarification

> 
> It looks like it uses the minimum over the last two and a quarter hours,
> give or take fence post effects, with a resolution of 15 minutes.
> 
>>
>> it is not clear to me even trying to figure it out from the source code
>> (seen 900 s sample rate... but I'm not sure to understand what all this
>> is about).
> 
> What problem are you really trying to solve?
> 

none, just checking how to best configure a NTP server in my own
situation. In fact I wonder whether it would make sense using

	tinker huffpuff 1048576

when all referred server have a maxpoll of 17

Edrusb wrote:
> Le 14/11/2016 à 11:25, David Woolley a écrit :
>> On 13/11/16 21:51, Edrusb wrote:
>>>
>>> in nptd, I wonder whether the huffpuff filter generates its own probes
>>> or relies on the (offset, delay) couples already available from the
>>> normal activity of ntpd (like for example the 8 samples visible from
>>> ntpq using "rv <association ID>" ).
>>
>> It doesn't produce its own probes; that would be pointless.
> 
> Thanks for clarification
> 
>>
>> It looks like it uses the minimum over the last two and a quarter hours,
>> give or take fence post effects, with a resolution of 15 minutes.
>>
>>>
>>> it is not clear to me even trying to figure it out from the source code
>>> (seen 900 s sample rate... but I'm not sure to understand what all this
>>> is about).
>>
>> What problem are you really trying to solve?
>>
> 
> none, just checking how to best configure a NTP server in my own
> situation. In fact I wonder whether it would make sense using
> 
> 	tinker huffpuff 1048576
> 
> when all referred server have a maxpoll of 17

Are you sure huffpuf even makes sense if the polling interval is as
large as 2^17 seconds?

Unless you have specific hardware with a very stable oscillator there
are good chances that the oscillator frequency changes significantly due
to ambient temperature changes during the long poll interval, so the
resulting accuracy may be limited anyway.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Le 16/11/2016 à 13:02, Martin Burnicki a écrit :
[...]
> 
> Are you sure huffpuf even makes sense if the polling interval is as
> large as 2^17 seconds?

Yes, this makes 36 hours... that's long I agree.

> 
> Unless you have specific hardware with a very stable oscillator there
> are good chances that the oscillator frequency changes significantly due
> to ambient temperature changes during the long poll interval, so the
> resulting accuracy may be limited anyway.

Of course! And it does change!

The fact is that with a maxpoll of 11, I usually get a clock jitter of
0.4 ms to 0.8 ms (the offset is usually less than +/- 0.5 ms) under
normal conditions due mainly to temperature variation and probably other
environment factors as you mentioned (I've checked power voltage but
could not find any correlation with observed important clock offsets).

When my DSL line is heavily loaded (downloading and/or uploading) the
clock offset increases by more than 20 ms seen the 'rv <assID>' output
from ntpq, even using Quality of Service (QoS) to prioritize sent NTP
packets (received packets are queued at operator router/DSLAM and this I
cannot change). However thanks to the huffpuff feature it seems such
measured high offsets (the delay increases by 30 to 40 ms) due to DSL
load are ignored as reported by the 'peers' command from ntpq.
Once the network load has dropped back, I usually observe a resulting
clock offset of less than 5 ms.

So now I just play with maxpoll to see how (un-)stable it gets.

Surprisingly, all 6 NTP referred servers reached yesterday the maxpoll
of 17 and the last measured offsets are between -3 and +2 ms (no DSL
load at that time on the DSL line). However one server had a -22 offset
due to an increase of 80 ms (!) latency which is not due to my DSL
line... The huffpuff mecanism did not seem to prevent this high offset
from been used in the mitigation algorithm (the 'peers' command report
that -22 ms offset unlike what I observed under heavy network load where
high offset got ignored), hopefully it got casted as outlier.
..
Where from my interrogation about the way the huffpuff feature works,
maybe I have set it too large and it got silently disabled due to out of
bound value... or it is too short and does not have enough substance to
work with, due to the extremely large maxpoll I've set...


> 
> Martin
> 

Regards,
Edrusb