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

unruh unruh at invalid.ca
Fri Nov 22 21:12:55 UTC 2013

On 2013-11-22, Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
> 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
> ports/winnt/ntpd/ntp_iocompletionport.c.

He says he is using a NIC which has hardware timestamping on it. Thus
the interrupt is irrelevant. The timestamping is already done before the
computer ever gets the packet. He wrote a driver (whever PCH stands
for). I guess the key problem with a hardware timestamp NIC is to get a
good estimate of the time difference between the NIC clock and the
system clock. 

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

More information about the questions mailing list