David,
In the code you cite the interplay between the deamon frequency and
kernel frequency was fragile and hard to follow. It is now more direct
and easy to follow. It's in the ntp-dev branch as part of the general
cleanup.
I put a good deal of effort into the ornamental commentary, but not as
much zeal as in the code itself, so sometimes the code might not do
exactly what the ornament says.
Dave
David Woolley wrote:
> Unruh wrote:
>
>>
>> And then line 595-597
>> ntv.modes |= MOD_FREQUENCY;
>> ntv.freq = (int32)((clock_frequency +
>> drift_comp) * 65536e6);
>
>
> This is immediately preceded by:
>
> /*
> * The frequency is set directly only if
> * clock_frequency is nonzero coming out of FREQ
> * state.
> */
> if (clock_frequency != 0) {
>
> I.e. the frequency setting is a one off.
>
>
>>
>>
>> And then the whole of /*
>> * adj_host_clock - Called once every second to update the local clock.
>> *
>> * LOCKCLOCK: The only thing this routine does is increment the
>> * sys_rootdispersion variable.
>> */
>
>
> Which starts with:
>
> /*
> * If clock discipline is disabled or if the kernel is enabled,
> * get out of Dodge quick.
> */
> if (!ntp_enable || mode_ntpdate || (pll_control &&
> kern_enable))
> return;
>
> I.E. the routine does nothing if the kernel discipline code is in use.
>
>>
>> This certainly produces an exponential decay.
>
>
> And is used for the user space clock discipline code.
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
