Re: [Linuxptp-devel] [PATCH RFC 20/30] interface: Introduce a method to test the time stamping information validity.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:13 AM, Richard Cochran wrote:
> On Tue, Feb 18, 2020 at 01:19:09PM -0800, Jacob Keller wrote:
>>> +bool interface_tsinfo_valid(struct interface *iface)
>>> +{
>>> +   return iface->ts_info.valid ? true : false;
>>> +}
>>
>> Do you actually need the ternary here? shouldn't ts_info.valid get
>> converted to true or false because we are returning a boolean?
> 
> Right.
>  
>> I don't think this is harmful and you may consider it improving
>> readability though.
> 
> Yeah, that is the reason.  I like to have it spelled out in this case.
> 
> Thanks,
> Richard
> 

Sure.

Thanks,
Jake


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


Re: [Linuxptp-devel] [PATCH RFC 14/30] interface: Introduce a method to set the name.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:06 AM, Richard Cochran wrote:
> On Tue, Feb 18, 2020 at 01:07:52PM -0800, Jacob Keller wrote:
>>
>> Good, the name is marked as constant. Side note, for those interface_*
>> functions that don't modify the interface, does it make sense to mark
>> them as taking a const interface pointer?
> 
> I have heard C++ people insisting on this, but frankly IMHO it doesn't
> make any sense.  If the implementation of the "class" is completely
> hidden, as it should be, then the caller should not care what happens
> offstage.  That is none of the caller's business.
> 
> Thanks,
> Richard
> 

Sure.

Thanks,
Jake


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


Re: [Linuxptp-devel] [PATCH RFC 24/30] interface: Introduce methods to create and destroy instances.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:19 AM, Richard Cochran wrote:
> On Tue, Feb 18, 2020 at 01:25:00PM -0800, Jacob Keller wrote:
>>
>> I still think it would be good to have the functions guarantee the NULL
>> by manually assigning or using one of the string copy implementations
>> that will guarantee it. That way they don't have to rely on this assumption.
> 
> In the final version, we have,
> 
>   char name[MAX_IFNAME_SIZE + 1]; 
>   
>  
>   char ts_label[MAX_IFNAME_SIZE + 1]; 
>   
>  
>   strncpy(iface->name, name, MAX_IFNAME_SIZE);
>   
>  
>   memcpy(iface->ts_label, iface->name, MAX_IFNAME_SIZE);  
>
>   strncpy(iface->ts_label, label, MAX_IFNAME_SIZE);   
>   
>  
> 
> so I think it is clear enough.  The use of MAX_IFNAME_SIZE is key.
> 
> Thanks,
> Richard
> 

Sure. It's not a big deal to me either way.


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


Re: [Linuxptp-devel] [PATCH RFC 28/30] interface: Hide the implementation details.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:24 AM, Richard Cochran wrote:
> On Tue, Feb 18, 2020 at 01:32:01PM -0800, Jacob Keller wrote:
>> I'd appreciate if there was some way to ensure we catch the interface
>> structure layout changing such that the definitions in clock.c and
>> config.c aren't compatible with interface.c anymore.
>>
>> Perhaps there isn't a good solution for that besides code review?
> 
> I am not too worried about the safety, because moving the list head
> will cause the whole thing to explode.  But there would be a better
> way.  The struct port has the same design, and so I'll address this
> issue with a follow up series.

Ok sounds good.

> 
> Thanks,
> Richard
> 


___
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] [PATCH RFC 07/30] Convert call sites to the proper method for getting interface names.

2020-03-05 Thread Jacob Keller
On 3/4/2020 8:59 AM, Richard Cochran wrote:
> On Tue, Feb 18, 2020 at 11:38:43AM -0800, Jacob Keller wrote:
>>
>> Is there a way to generate the network of how interconnected the various
>> object files are?
> 
> The .d files have the includes.  I once wrote a script to turn the .d
> files into a dotty graph.  But I guess the utility is low.
> 
> Thanks,
> Richard
> 

Right.

Thanks,
Jake


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


Re: [Linuxptp-devel] [PATCH RFC 06/30] interface: Introduce an access method for the name field.

2020-03-05 Thread Jacob Keller
On 3/4/2020 8:56 AM, Richard Cochran wrote:
> On Tue, Feb 18, 2020 at 11:33:32AM -0800, Jacob Keller wrote:
>> So the interface.o isn't being added to something like $(CONFIG)?
> 
> I like the idea, but I'll leave that as a follow-on task.
> 
> Thanks,
> Richard
> 

Yea makes sense. I don't see a reason to hold up this series due to that.


___
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