[ntp:questions] Slow convergence loopstats (but nice results)
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
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
> 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