[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