Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-06 Thread Frantisek Rysanek
On 6 Mar 2020 at 16:42, linuxptp-devel wrote:
> And the funny point is: while the E2E transactions result in no 
> asymmetry, the P2P transactions result in about +60 nanoseconds
> of additional asymmetry. That's curious...
>
...actually I should've quoted that as -60 nanoseconds.
In addition to the -20 ns on a direct connection.
The total hovers around -80 ns offset.

Frank


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-06 Thread Frantisek Rysanek
Just a snippet of a funny observation:

I've discovered the config parameter "clock_servo nullf" .
Very good - that answes another need I had:
to let the PHC freewheel along the ultimate external reference
(10MHz -> PLL_synth -> 25 MHz from the PTP GM out of band),
and let ptp4l do the talk and calculate the delays and offsets 
that it can obsereve on the network.
It seems to work fine. On a real-wold network I may also need 
to raise the bar for step-wise adjustment (for this measurement to 
proceed unhampered).

Just to test if it works, I've tried L2 multicast through an old 
D-Link DGS-1216T. It does work, the (p)delay is about 2 microseconds.
The switch does let both P2P Pdelay and E2E Delay through just fine.

And the funny point is: while the E2E transactions result in no 
asymmetry, the P2P transactions result in about +60 nanoseconds
of additional asymmetry. That's curious...

That's over two metallic gigabit hops.
For comparison, straight against the GM, I have about 7 or 10 ns of 
(p)delay and about -20 ns of asymmetry, which may well correspond to 
the length of my PPS cabling (that I use to pre-settle the PHC).

Yes I'm having fun with my toys :-D

Frank


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-06 Thread Frantisek Rysanek
On 5 Mar 2020 at 17:01, Jacob Keller wrote:
> On 3/5/2020 1:11 AM, Frantisek Rysanek wrote:
> > 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.
> 
> So, the SYSTIMR field is not "used" directly, but it holds and maintains
> fractional nanoseconds. When you adjust the increment value slightly,
> these get added to the SYSTIMR field of the system time. As that slowly
> increments and eventually overflows, it will then increment the SYSTIML
> register.
> 
> Essentially we always round down by cutting off SYSTIMR.
>
Mr. Keller thanks for your polite explanation :-)

I have to say that the i210 is a very nice piece of silicon to play 
with :-) I'm aware that at 1 GHz / fractions of a ns, it takes some 
cunning design to make a synth with this kind of fine adjustment, 
immediate response and nanosecond resolution,
with hardly any jitter/phase noise. It's a job well done.

The fact that timestamping external events is granular at 8 ns 
("only") does not offend me. I'm aware that it's difficult
to run counters and atomic latches that fast.
I've read something about WhiteRabbit's phase detector,
called the DDMTD - which supposedly can measure phase
differences down to the picosecond range. If I understand correctly,
that comparator block depends on having isochronous clocks
(the reference and the measured input) much faster than 1PPS
and hinges on down-mixing those clocks, then phase comparison
and statistics (filtering) to arrive at that fine-grained result.
Hence also WhiteRabbit's dependence on SyncE,
and the BC-only nature of their PTP-aware switches...
I understand that this is what it takes to run time-sync
over a WAN at ns/sub-ns level preecision...

Frank Rysanek



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-05 Thread Jacob Keller
On 3/5/2020 8:19 AM, Frantisek Rysanek wrote:
> during the initial settling of the PHC frequency / servo loop,
> I can see offsets in low units of ns, not aligned in any way.
> But: once the PHC settles to offset==0 && ppb==0,
> any measured edges captured via EXTTS channel 0 or 1
> will be quantised on 8ns boundaries.
> This is kind of spooky :-)
> Maybe the quantisation just doesn't jump at me so bad
> while the frequency (ppb) is still a little off...
> and it's true that if I keep capturing on both channels,
> their mutual difference is always quantised at 8 ns,
> even though the difference against the internal unsettled
> PHC is not aligned that way.
> 
> I'm giving up this train of research.
> Comments welcome :-)
> 8 ns granularity is better than nothing at all.

This makes sense. The clock source has a period of 8 ns of I recall. We
only update once every period. In order to have lower granularity, you'd
have to update at a higher rate.

We can change the exact amount that we update by modifying INCVAL, but
that doesn't change the underlying clock source. Thus, significantly
different INCVALs would not produce multiples of 8, but if you
eventually sync down to a ppb of 0 it would end up being there.

Thanks,
Jake


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-05 Thread Jacob Keller
On 3/5/2020 1:11 AM, Frantisek Rysanek wrote:
> 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.

So, the SYSTIMR field is not "used" directly, but it holds and maintains
fractional nanoseconds. When you adjust the increment value slightly,
these get added to the SYSTIMR field of the system time. As that slowly
increments and eventually overflows, it will then increment the SYSTIML
register.

Essentially we always round down by cutting off SYSTIMR.


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-05 Thread Frantisek Rysanek
...so I've tried myselfs. 
I've re-written my proggie to first settle the PHC using EXTTS CH0
to the external reference PPS, and then switch EXTTS CH0
to the measured PPS signal (reconfigure the CH0
to take input from the second SDP input).
Guess what: the measured deviations are still quantised per 8 ns.

So to sum up:
during the initial settling of the PHC frequency / servo loop,
I can see offsets in low units of ns, not aligned in any way.
But: once the PHC settles to offset==0 && ppb==0,
any measured edges captured via EXTTS channel 0 or 1
will be quantised on 8ns boundaries.
This is kind of spooky :-)
Maybe the quantisation just doesn't jump at me so bad
while the frequency (ppb) is still a little off...
and it's true that if I keep capturing on both channels,
their mutual difference is always quantised at 8 ns,
even though the difference against the internal unsettled
PHC is not aligned that way.

I'm giving up this train of research.
Comments welcome :-)
8 ns granularity is better than nothing at all.

Frank
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_cmp2.c
 Date:  5 Mar 2020, 17:01
 Size:  28791 bytes.
 Type:  Program-source


i210_ext_pps_cmp2.c
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, 16:57
 Size:  26939 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


[Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-05 Thread Frantisek Rysanek
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