John,
I mislead you. As you correctly note, the fudge doesn't work if the atom
driver uses the kernel signal directly. As the code suggests,
performance is usually better if you don't use the PPS kernel interface.
The median filter in the atom driver is much longer than in the kernel
and the kernel PLL frequency resolutino is better. That's why I
defaulted the kernel interface off.
Having said that, it is probably a good idea, if nothing else for
consistency, to incorporate your patch in the atom driver.
Dave
David L. Mills wrote:
John,
The PPS driver (refclock_atom.c) does indeed support fudge. I have tried
to convince the various GPS driver authors to abandon per-driver PPS
code in favor of using the atom driver, so all PPS stuff would be in one
place, but I have not been successful. Therefore, each driver is on its
own.
Dave
John Pettitt wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Mauro Fiacco wrote:
I was expecting to be able to use a fudge factor (time1) in order tell
ntpd the offset of my pps source... but without much success.
There is your problem - the pps drivers don't correctly support fudge
factors - if you search through the bug database @ ntp.org you'll fidn
a patch I did for the NMEA driver PPS code to correctly support fidge
factors - you could, I suspect, very easily apply the same code to the
PPS driver and get the rtesult you are looking for.
John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDTAhnaVyA7PElsKkRA8JwAJsGbKIhJPrZ+2ZWxiDO5ELsF7oLnACg8+gB
n0ZH7r35VjD5R0ii8aU8IOI=
=iNny
-----END PGP SIGNATURE-----
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
