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

Attachment: 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

Attachment: 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

Reply via email to