On 2013-11-22 14:12, unruh wrote:
On 2013-11-22, Brian Inglis <[email protected]> wrote:
On 2013-11-22 09:19, [email protected] 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.
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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
