[ntp:questions] Slow convergence loopstats (but nice results)
unruh at invalid.ca
Fri Nov 22 17:38:36 UTC 2013
On 2013-11-22, schmidt.rich at gmail.com <schmidt.rich at gmail.com> wrote:
> I have just written a PHC driver for NTP and tested it on this system:
> Supermicro SYS-50150EHF-D525 which has a pair of Intel 82574L NICs which
> have IEEE 1588 hardware-based timestamping. I'm using NTP dev 4.2.7p397 on Linux kernel 3.12 with linuxptp. One of the PHCs is sync'd via PTP to an FEI Zyfer Gsync GrandMaster, which is in turn synced via 5MHz to the USNO Master Clock #2.
> I'm running ptp4l to sync PHC1 to the GrandMaster. Then NTP is reading the refclocks PHC0, PHC1 and an NTP server on the LAN ptp2:
> ntpq -p
> remote refid st t when poll reach delay offset jitter
> +PHC(0) .PTP. 0 l 15 16 377 0.000 0.000 0.000
> *PHC(1) .PTP. 0 l 2 16 377 0.000 -0.001 0.000
> +ptp2 .IRIG. 1 u 38 64 377 0.123 0.018 0.007
> After about 15 hours the loopstats shows a s.d. of +/- 0.579 microsec with peak-peak 2.52 microsec (3,073 points). Very superb.
> However, it took fully 75 minutes at start to converge. It took that long to remove 20ms of phase error. I have never seen such a slow convergence. Very smooth too. I have tested the NMEA/ATOM drivers on this system and the convergence was the normal few minutes. Any suggestions? Can email plots.
David Mills has always stated that rate of convergence is not a problem
he cares about at all. Stability of running is. ntpd is NOT designed to
converge quickly. If you want faster convergence ( and better clock
discipline although possibly slightly higher drift noise) use chrony.
Certainly a SD of .5us is far better than any standard PC can get from
an interrupt driven stratum 0 source due to
interrupt latency fluctuations. I am surprized you can get such good
results from a NIC based solution (even with hardware timestamping).
> Rich Schmidt
> Time Service Dept
> US Naval Observatory
More information about the questions