Dear gentlemen, after two years of silence, I've played some more with my multiport i210 test rig... I now have 4 ports of i210, two of them metallic, two of them fiber optic (with Gigabit SERDES SFP slots). And I've hacked the optical cards to have SDP0 and SDP3 inputs, as well as the obvious 25MHz reference input (referenced by a PLL synth to 10 MHz phase-synchronous with PPS from a GPS clock). The metallic cards have all four SDP inputs available ex works on a header.
= I have a box with 4 ports of i210, their 25 MHz referenced to GPS, phase-synchronous with a PPS reference that I'm using to discipline the four PHC's... And, I have an extra SDP input and EXTTS channel per i210 PHC, available for misc timestamping purposes (right now for PPS deviation measurements). I'm attaching an example proggie and a snippet of its TXT output. And finally to the point = my question for today: The servo loop that I'm using to discipline the PHC based on external PPS - that converges smoothly while printing a convergent row of nanosecond numbers. After a couple seconds, the offset and frequency end up at 0. This is what I achieved two years ago, based on Mr.Cochran's work - I got the whole thing basically finished from him. The series of numbers, produced by the servo lop convergence, seems clearly granular down to a nanosecond. But, the funny point is: if I use a second EXTTS channel to timestamp a second PPS input, that second input seems "quantised" at 8ns granularity to the reference PPS input. To the extent, that while the reference servo hasn't entirely settled yet, I'm getting non-quantised readings from the second EXTTS channel too - non-quantised against the internal timebase. But, always quantised at 8 ns granularity against the reference PPS input. I've read in the i210 datasheet that "During run time the SYSTIM timer value in the SYSTIMH, SYSTIML and SYSTIMR registers, is updated periodically each 8 nS clock cycle" etc And there's a note in drivers/net/ethernet/intel/igb/igb_ptp.c that "The 82580 timesync updates the system timer every 8ns by 8ns, and this update value cannot be reprogrammed." So the i210 has probably moved ahead a little, since the 82580 generation, but in some form that 8ns granularity is still there. I'm wondering if I should first discipline the clock by PPS ref plugged in the EXTTS CH0, wait for the frequency offset to settle down to 0 for a few periods, then stop updating the servo and switch the EXTTS CH0 to the "measured PPS signal". If that can possibly yield the desired granularity down to a nanosecond. I will probably just try :-) Any comments welcome. And another sideways question is: in the i210 hardware, there's a register called SYSTIMR, supposedly holding the fraction of a nanosecond (= sub-nanosecond resolution). And this register is ignored by the igb driver in Linux - first and foremost because the internal timestamping infrastructure only supports nanosecond resolution. I know that a "ns fraction" field is present in the PTP frames, but everybody except the White Rabbit just leave that field empty (all zeroes). I'm wondering if this SYSTIMR register in the i210 hardware has some practical use, or is always zero, or what. Well for my practical purposes, the SYSTIMR does not get reflected in the two AUXSTMP registers - so I can probably just ignore SYSTIMR too. I'm wondering if it's safe to assume that once the servo has converged to 0 frequency offset, that I can stop updating the frequency (knowing that I have the PHC's upstream oscillator disciplined "out of band"). Or if there's some fractional part that can cause the internal PHC clock to drift (the internal PHC clock is synthesized based on the XTAL as a reference and a correction value updated by the servo loop). Theoretically I could just set the frequency correction to 0. Not sure if the ptp4l internal API allows me to do that. And the servo has its role in the initial adjustment/alignment of the PPS event in time, as the servo mechanism ends up being more precise than a direct register write (that's only any good as a coarse initial stepwise adjustment). Again any comments welcome, thanks for your attention, have a nice day :-) Frank Rysanek
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: ext_sync_example3.txt Date: 5 Mar 2020, 9:07 Size: 16184 bytes. Type: Text
ext_sync_example3.txt
Description: Binary data
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: i210_ext_pps_cmp.c Date: 5 Mar 2020, 9:10 Size: 26346 bytes. Type: Program-source
i210_ext_pps_cmp.c
Description: Binary data
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel