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
![]() |
0 |
![]() |
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?
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |