[ntp:questions] Re: NTP server with Rubidium PPS

David L. Mills mills at udel.edu
Fri Oct 14 01:36:00 UTC 2005


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-----




More information about the questions mailing list