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. > > 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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
