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

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Fri Nov 22 19:31:53 UTC 2013

On 2013-11-22 09:19, 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 onLinux
> kernel 3.12 with linuxptp. One of the PHCs is sync'd via PTP to an FEIZyfer
> 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..
> Rich Schmidt
> Time Service Dept
> US Naval Observatory

You do not appear to be delivering PPS via kernel PPS, an ATOM driver, or user mode
PPS, with PHC0/1 as your prefer peer. You want to see o before your ref clock, so
that may explain slow convergence compared to using the ATOM driver!

Does Linux PTP have an interface to provide timestamp interrupts to Linux kernel PPS,
and can you set that up, or add user mode PPS to your driver? There are example user
mode PPS patches for Raspberry Pi Raspian Linux NTP, and in

You could compare your loopstats to your ref clock peerstats, and also your driver
clockstats if you are generating them?
Loopstats offset/jitter should track your ref clock peerstats offset/jitter exactly,
and comparing to your clockstats may point you to causes.
Take care. Thanks, Brian Inglis

More information about the questions mailing list