On 2019-08-17, Michael Haardt <mich...@moria.de> wrote: > Miroslav Lichvar <mlich...@redhat.com> writes: >> I think you do. To prevent the source from being rejected as a >> falseticker it needs to have a larger root distance. That could be from >> a larger dispersion or delay. You modified the refclock jitter, which >> ends up in the peer dispersion (after some weighting). Another approach >> would be to specify a minimum for the peer dispersion directly. There >> could be also an option to specify a minimum delay. But adjusting it in >> the refclock specific code, as you did, makes perfect sense to me. > > Which of the alternatives do you prefer? I got one way working, but I > am willing to test any other in case you have a patch or could at least > tell me where to enforce the minimum in the code to create a patch.
>From the three approaches I'd probably prefer yours, i.e. keep it as a refclock-specific option. But maybe see if there is a better name for the option. "minjitter" might be confusing, at least in my understanding of the NTP terminology. If you would like to try the other suggestions, I think they could be implemented in the clock_filter(), clock_select(), or root_distance() function. > In the end, it would be great to get the needed functionality into > ntpd. If you want to get it in the ntp code, you should open a bug in the ntp bugzilla, attach the patch, and see what the maintainers think. -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
