[ntp:questions] Slow convergence loopstats (but nice results)

schmidt.rich at gmail.com schmidt.rich at gmail.com
Mon Dec 9 20:35:09 UTC 2013


On Saturday, November 23, 2013 1:20:37 AM UTC-5, Brian Inglis wrote:
> On 2013-11-22 14:12, unruh wrote:
> My point is that without other indicators, these are just another bunch of ref clock
> 
> timestamps being delivered into the discipline control loop.
> 
> When these are known to be high quality samples, that needs to be indicated to ntpd
> 
> by adapting the PPS and/or kernel APIs, as those appear to be the only ways to
> 
> influence ntpd, as documented at http://www.eecis.udel.edu/~mills/ntp/html/extern.html
> 
> under External Clock Discipline.
> 
> -- 
> 
> Take care. Thanks, Brian Inglis

Well Brian, if what you say above was a correct understanding of Mill's documentation, USNO could not have influenced the NTP stratum 1 business since back in 1996. In truth NTP is designed to obtain time of day from refclocks via the refclock_process() routine which allows one to stuff a refclockproc structure with time of day from a clock, and this is what USNO has always done. 

 My new prototype driver refclock_phc() uses as its clock the PTP Hardware Clock (PHC) found on one of the newer LAN NICs which are PTP (IEEE 1588) aware. This driver is producing phenomenal results (under LINUX 3.12 with linuxPTP): the overlapping Allan deviation computed from loopstats phase offsets alone reaches a stability of 6e-12 in under 2e5 seconds, and the modified Allan deviation reaches 2e-13.  

This is quite useful, as eventually most all NICs will be PTP-enabled, and can be used as slaves as above, or even GrandMasters (with GPS, for example). 

I will ship my driver to Network Time Foundation when it is completed. This is a practical realization of PTP-NTP partnering in a refclock driver!
Regards, 
Rich Schmidt



More information about the questions mailing list