[ntp:hackers] Re: The ATOM Driver.
David L. Mills
mills at udel.edu
Sat Feb 18 01:52:51 UTC 2006
Reg,
Not so fast. The kernel discipline and PPS discipline are independent of
the atom driver and even ntpd itself. The driver does use the kernel
discipline, which is the only way to avoid sawtooth errors. In older
systems with relatively high jitter due to queue, I/O and serial port
latencies, the atom driver is preferred because the length of its median
filter is much greater than the kernel filter. In modern 3-GHz systems
the kernel PPS discipline would very likely outperform the atom driver.
I left the default to use the kernel discipline rather than direct
kernel PPS interface as the conservative selection. In comparison with
other things I see in modern kernels, the PPS code bloat is microscopic.
After all, the kernel components have been in Digital kernels since 1992
and in Solaris kernels for something like ten years.
Scrunching the atom code to the daemon would be very awkward. The design
philosophy has been to banish things like serial and parallel ports to
specialized drivers. The PPS signal is special in that it needs another
driver or server to number the seconds, watch for errors and so forth.
Also, the PPS signal itself has some degree of fragility, as it usually
needs a separate cable, level converter and Wye connector contraption.
In the current design the mitigation algorithms nicely solve the error
and fallback problem.
I don't understand your question. I have not asked the GPS drivers to
change to use the atoms; I have suggested to remove the PPS code
entirely and let the atom driver do the work. The one thing the drivers
would need to change is to increase the root distance to something a
little more than the peak-peak timecode jitter. That would be a good
thing and avoid lying to the mitigation algorithms.
Dave
Reg Clemens wrote:
> This is a question for Dave:
>
> In previous notes you have said that the changes you have made in
> the ATOM driver causes the timekeeping in the user version of ntpd
> to be better than ntpd implemented in the kernel (kernel variable set).
>
> I think thats great, as kernel folks are never happy with extra code,
> and this would allow us to reduce our kernel presence without reducing
> the accuracy of the timekeeping.
>
> My question then, is why is this code still in the ATOM driver?
> Why ask all the driver maintainers to change their code to use ATOM?
>
> Why not just push the code you have built into ATOM up into NTPD itself,
> and they you could get rid of ATOM altogether.
> Everyone would instantly get the advantage of your code.
>
> With the PPSAPI things are as clean as they are ever going to be in
> the various drivers, and it seems that transferring control from one
> driver to another (ATOM) just complicates things.
>
More information about the hackers
mailing list