linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Richard C. <ric...@gm...>]

On Tue, Mar 15, 2022 at 06:11:26AM -0700, Axel Simon wrote:

> Is there something I'm missing here? Is there any documentation or recommendation regarding the design of a high-accuracy linuxptp-based system?

No, you stated the facts well enough.

If you want to make a single port GM, then you might want to provide
it with a global time source.  Let's assume you are using the i210.
You have some choices.

1. Configure the i210 as --free_running=1 (not a global time source at
   all.  But it might be okay to synchronize a "time island" depending
   on your application requirements).

2. Run NTP client on the Linux host, and use phc2sys to sync PHC with
   Linux system time.  Might end up milliseconds offset from global
   time due to NTP performance alone.

3. Attach GPS PPS to, say, Linux serial port, and use phc2sys to sync
   PHC with Linux system time.  Not a great solution, because of poor
   time stamps from the Linux kernel PPS subsystem.

4. Attach GPS PPS to i210 SDP.  This is the best solution.  With a
   healthy GPS fix, your GM will be easily within a few hundred
   nanoseconds of global time.  That is without any special tuning.

Now, if your GM has more than one port, then of course you will want
to use design #4 and feed the PPS to i210 cards in parallel.
(Alternately you could feed PPS into one card, then generate a PPS
from that card to the others.)

It is your design.  You have your application requirements.  You can
make whatever engineering decisions you wish.

But please don't spread FUD about linuxptp.

Thanks,
Richard

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Axel S. <axe...@go...>]

Hi Richard,

> On Mar 11, 2022, at 6:51 AM, Richard Cochran <ric...@gm...> wrote:
> 
> On Fri, Mar 11, 2022 at 06:30:49AM -0800, Axel Simon wrote:
> 
>> Sorry, I checked again and I stand corrected. We saw some offsets
>> before we were able to monitor our system properly and it's still in
>> my head that we can't get better than 2µs of noise. We are
>> synchronizing the PTP clocks between different NICs using phc2sys
>> and connect two x86 systems.
> 
> Right, using phc2sys is not a great design for a GM.
> 
> Why?
> 
> because it uses SW time stamping.
> 
> But that is not the fault of the i210 card.
> 
> If you were to feed a 1 PPS from a GPS radio into the SDP of the i210,
> for example, then you get your time error well below 1 usec.
> 

Earlier you wrote:

> 
> For PCIe MACs, their PTP synchronization performance is NOT affected by PCIe latency.
> 
>> Interesting. For my application (telecom) I definitely need accuracy in the
>> range of 1.5us.
> 
> Easy to get the i210 to within a few dozen nanoseconds without doing
> anything special.

I find these statements a bit confusing.
What do you mean by "PTP synchronization performance" if it is not the ability to synchronize to other NICs?
"Not doing anything special" sounds to me like using phc2sys to synchronize various clocks in an x86 system. But then you say "phc2sys is not a great design for a" grandmaster. The only way to synchronize several devices with an accuracy of ~100ns using ptp4l seems to be
(a) using several NICs, but synchronizing them via some PPS wires or
(b) using a single NIC, and a PTP-enabled Ethernet switch
I don't think that (a) classifies as "not doing anything special" and (b) is probably not what people think of naturally when they plan  on using ptp4l as a boundary clock or master.

Is there something I'm missing here? Is there any documentation or recommendation regarding the design of a high-accuracy linuxptp-based system?

Cheers,
Axel

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Richard C. <ric...@gm...>]

On Sun, Mar 13, 2022 at 07:01:28PM +0100, Andre Puschmann wrote:

> Are you using the HW, i.e. the TSSDP register or configure the SDP as input
> and update the value in the ISR?
> 
> For example, taking a PPS output (in my case 5V), level shifted to 3.3 and
> feeding it to, e.g. SDP3, of the i210-T1. How should I configure the TSSDP
> register to let the PPS pulse sync the TS value?

The ts2phc program does all of that already.  It uses standard APIs,
and so you can also roll your own, using ts2phc as a learning tool for
the APIs.

HTH,
Richard

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Andre P. <and...@sr...>]

Hey,

On 11/3/22 15:51, Richard Cochran wrote:
> If you were to feed a 1 PPS from a GPS radio into the SDP of the i210,
> for example, then you get your time error well below 1 usec.

That's exactly what this thread is about. However, I am still not fully 
understanding what's needed for that, especially the update mechanism 
for the TXSTMP register.

Are you using the HW, i.e. the TSSDP register or configure the SDP as 
input and update the value in the ISR?

For example, taking a PPS output (in my case 5V), level shifted to 3.3 
and feeding it to, e.g. SDP3, of the i210-T1. How should I configure the 
TSSDP register to let the PPS pulse sync the TS value?

Are there any driver patches needed or are all necessary knobs exposed 
over the /sys interface?

Thanks
Andre

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Richard C. <ric...@gm...>]

On Fri, Mar 11, 2022 at 06:30:49AM -0800, Axel Simon wrote:

> Sorry, I checked again and I stand corrected. We saw some offsets
> before we were able to monitor our system properly and it's still in
> my head that we can't get better than 2µs of noise. We are
> synchronizing the PTP clocks between different NICs using phc2sys
> and connect two x86 systems.

Right, using phc2sys is not a great design for a GM.

Why?

because it uses SW time stamping.

But that is not the fault of the i210 card.

If you were to feed a 1 PPS from a GPS radio into the SDP of the i210,
for example, then you get your time error well below 1 usec.

Thanks,
Richard

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Richard C. <ric...@gm...>]

On Thu, Mar 10, 2022 at 09:47:21PM +0100, Andre Puschmann wrote:

> > We found that ptp4l can only synchronize NIC clocks (e.g. i210) to an accuracy of ~2µs due to the latency PCIe transactions. If you want better synchronization, ptp4l with off-the-shelf NICs is not a solution.

FUD

For PCIe MACs, their PTP synchronization performance is NOT affected by PCIe latency.

> Interesting. For my application (telecom) I definitely need accuracy in the
> range of 1.5us.

Easy to get the i210 to within a few dozen nanoseconds without doing
anything special.

Thanks,
Richard

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Andre P. <and...@sr...>]

Hi Axel,

On 10/3/22 21:23, Axel Simon wrote:
> Your subject has "disciplined oscillator" in it. That sounds like you want ptp4l to carry the time forward while there is no GPS reception. Thus, it seems that you have a setup where your GPS receive does not have a lock to GPS at all times.

Not quite. But perhaps my explanation wasn't sufficient. What I have is 
an external device that is GPS synced and has 10MHz/1PPS output. Even if 
it's not GPS locked, the oscillator is much better and so the 1PPS 
output will be stable.

What I am actually interested in is using the 1 PPS reference and 
discipline the NIC's oscillator.

I am still not quite sure to which extend this would improve the 
timestamp accuracy.


> We found that ptp4l can only synchronize NIC clocks (e.g. i210) to an accuracy of ~2µs due to the latency PCIe transactions. If you want better synchronization, ptp4l with off-the-shelf NICs is not a solution.

Interesting. For my application (telecom) I definitely need accuracy in 
the range of 1.5us.

In your statement, are you referring to off-the-shelf NICs acting as 
slaves or master?
Also, are you referring to unmodified off-the-shelf NICs or modified, 
i.e. disciplined or equipped with higher quality oscillators?

Thanks
Andre

> 
> Cheers,
> Axel
> 
>>
>>> However, making a reliable GM product is quite a bit of work.  The PTP
>>> software stack is only one piece of the puzzle.
>>
>> Yes of course. This effort is just to develop a poor man's GM as a PoC.
>>
>> But nonetheless interesting to observe that there is practically no NIC out there that brings together all the pieces. Should be quite easy to do. Cards like the Intel XXV710-DA2T or E810-XXVDA4T with GPS input are hard to get and $$$.
>>
>> Thanks
>> Andre
>>
>>
>> _______________________________________________
>> Linuxptp-users mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
> 


-- 
Andre Puschmann

Software Radio Systems (SRS)
https://www.srs.io
an...@sr...

PGP/GnuPG key: 0x204A85DFEA324D58
fingerprint: 3924 1C60 D52E 81A2 1F2E 0C9D 204A 85DF EA32 4D58

Re: [Linuxptp-users] Time synchronous jump protection

[Miroslav L. <mli...@re...>]

On Thu, Mar 10, 2022 at 11:40:38AM +0800, ron wrote:
> last cycle: master time: 100ms slave time( sync with master correctly)：100ms
> next cycle: master time:150ms(produce abnormal jump 50ms)
> slave time( can not accept such a huge jump, maximum 1ms)：101ms（expected value）

If I understand this correctly, you would like to limit the frequency
offset of the clock. ptp4l has the max_frequency option for that. See
the man page.

-- 
Miroslav Lichvar

[Linuxptp-users] Time synchronous jump protection

[ron <ron...@16...>]

hello,


    I'd like to inquire about the abnormal jump of time synchronization， The questions are as follows：
after the time synchronization is stable, if the master clock has an abnormal jump (for example, the time suddenly jumps for 100ms or more), how can the slave side set and recognize this abnormal jump, and synchronize the local time with a maximum amplitude (for example, 1ms) (similar to the maxwrite configauration of Chrony).
example:
last cycle: master time: 100ms slave time( sync with master correctly)：100ms
next cycle: master time:150ms(produce abnormal jump 50ms)
slave time( can not accept such a huge jump, maximum 1ms)：101ms（expected value）


 when the master have a huge jump, can the slave synchronize with a set maximum synchronization amplitude(for compensation)?






Thanks

Re: [Linuxptp-users] Master offset is higher when ptp clock updates in every second

[Miroslav L. <mli...@re...>]

On Wed, Mar 09, 2022 at 04:35:37PM +0530, Raj wrote:
> what is the command to use:
> 
> option 1: "phc2sys -d /dev/pps0 -c CLOCK_REALTIME -c /dev/ptp0 -o 0"

There can be only one -c option and with -d it has to be the system
clock.

> option 2: "phc2sys -d /dev/pps0 -c CLOCK_REALTIME -o 0
>                 phc2sys -s CLOCK_REALTIME -c /dev/ptp0 -o 0"

This could work, assuming /dev/pps0 is not a PPS device of /dev/ptp0.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] Master offset is higher when ptp clock updates in every second

[Raj <mai...@gm...>]

Hi Richard,

Thanks for the info.

We are trying to synchronise "/dev/ptp0" with 1_PPS.  First time, system
clock "CLOCK_REALTIME" will be properly adjusted with correct time (GPS) then,
we want to use /dev/pps0 as the source for system clock as well as /dev/ptp0


what is the command to use:

option 1: "phc2sys -d /dev/pps0 -c CLOCK_REALTIME -c /dev/ptp0 -o 0"


option 2: "phc2sys -d /dev/pps0 -c CLOCK_REALTIME -o 0
                phc2sys -s CLOCK_REALTIME -c /dev/ptp0 -o 0"


Thanks in advance.


Thanks,

Raj

On Tue, Mar 8, 2022 at 7:55 PM Richard Cochran <ric...@gm...>
wrote:

> On Tue, Mar 08, 2022 at 06:38:50PM +0530, Raj wrote:
>
> > We used "clock_settime(clockid_t clockid, const struct timespec *tp)" to
> > update the ptp clock in every second based on dsp time.
>
> That is surely the wrong way.
>
> > We have also tried to adjust the ptp clock frequency and step using
> > "clock_adjtime()" every 1 second. However, we still observe higher master
> > offset in slave.
>
> Maybe your servo is unstable?
>
> > Could you please suggest how to update ptp clock (/dev/ptp0) with 1_PPS
> > (dsp time) without increasing master offset considerably.
>
> Making a proper GM is a real engineering challenge.  The PTP software
> stack is only one part of the puzzle.  We can't do your engineering
> for you on this list.
>
> Sorry,
> Richard
>

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Andre P. <and...@sr...>]

On 8/3/22 15:33, Richard Cochran wrote:
>> I was wondering if someone has used this successfully at all?
> 
> Yes, I would guess so.

Is there a write-up or something similar available you know?


>> In general, what are the steps to set this up? Is this something managed in
>> the NIC driver itself or do I have to (permanently) run the `ts2phc` to keep
>> to PHC in sync?
> 
> You need to run ts2phc or similar.  In general, the NICs are dumb devices.

Got you. Thanks.

>   
>> Are there studies/measurements that compare the stability of such a system
>> to e.g. commercial PTP grandmaster solutions?
> 
> I haven't seen any.  I've done my own reports showing, for example,
> linuxptp + Intel210 + uBlox GPS radio performing comparably to
> commercial GM solutions.

Same question, anyone aware of a write-up or blog post that gives some 
instructions on HW wiring and (if any) driver modifications?


> However, making a reliable GM product is quite a bit of work.  The PTP
> software stack is only one piece of the puzzle.

Yes of course. This effort is just to develop a poor man's GM as a PoC.

But nonetheless interesting to observe that there is practically no NIC 
out there that brings together all the pieces. Should be quite easy to 
do. Cards like the Intel XXV710-DA2T or E810-XXVDA4T with GPS input are 
hard to get and $$$.

Thanks
Andre

Re: [Linuxptp-users] GPS + PPS PTP master - confusion about ts2phc, phc2sys, ptp4l options and interdependencies

[<ma...@ma...>]

> -----Original Message-----
> From: Richard Cochran <ric...@gm...>
> Sent: Tuesday, March 8, 2022 3:51 PM
> To: David Jedynak <sil...@gm...>
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] GPS + PPS PTP master - confusion about
ts2phc,
> phc2sys, ptp4l options and interdependencies
> 
> On Tue, Feb 22, 2022 at 01:50:39PM -0600, David Jedynak wrote:
> > For use case orientation: Embedded system installed on a remote (no
> > internet) infrastructure, receives GPS w/PPS, sets time from power-up
> > (e.g. 1970) and acts as PTP grandmaster for the entire local
> > infrastructure.  Hardware includes intel i210 with PPS input to SDP3
> > (this cannot be changed, hardware already exists).  Occasional loss of
> > GPS signal for a few seconds (< 10) at a time is expected, but no
> > sophisticated clocks (e.g. TCXO or atomic) needed for better
> > hold-over.
> >
> > General query: With linuxptp 3.1 and newer (since ts2phc was added),
> > it has become a bit confusing how to stitch together all the bits and
> > how they interact. I see a caution in the ts2phc man page about
> > sharing config files and overlapping options. Seems like
> > clarification is needed.  Are these assumptions below correct?
> 
> You do need to stitch the pieces together yourself, especially things
> like monitoring GPS health/quality are yours to implement.

Sometimes you can use the GPS's ability to squelch the 1PPS out when it
loses track of satellites and monitor ts2phc logs for that purpose.

> WRT configs files:  The warning is only there because each program
> might need different options. So the simple way is to provide each
> program its own file.
> 
> > Assumption #1:  ts2phc and associated config file is how I configure
> > the input (e.g. SDP3 on the i210) and some very basic options
> > regarding pulse width.  ts2phc also has a NMEA option - stick a pin in
> > that (see below).  ts2phc doesn't seem to have anything for actually
> > configuring servo loops other than some step options. Correct?
> 
> No. You can choose the servo too.

Out of curiosity - do you need a servo there? Usually, we put them where we
expect some randomness (PDV in PTP or time read jitter in phc2sys). The
GNSS usually has low jitter and is local to the device and hence doesn't
need much filtering.

> > Is
> > this why ts2phc run all by itself (no phc2sys running) has a bunch of
> > (null) for clock related config items (e.g. "(null).clock_servo",
> > "(null).pi_proportional_cont", etc.)? Am I missing something?
> 
> No, that is not the reason, but don't worry about the "null" debug
> message. It doesn't indicate an error.
> 
> > Assumption #2:  phc2sys and associated config file is how I configure
> > servo loops (how do those interact w/ts2phc that's actually getting
> > the pulses?)?
> 
> Well, each program has its own servo.
> 
> > It looks like phc2sys is how to link the phc to system
> > time, and there are options for *sys* to set PHC Time of Day, or PHC
> > to set *sys*, depending on the architecture's end goal and use case,
> > right?
> 
> Yes. But you don't want to let phc2sys change the PHC. ts2phc will
> take that job.
> 
> For a GPS GM, you don't actually need phc2sys at all. It is merely a
> nice-to-have when the Linux system time also follows the GPS.
> 
> > Assumption #3: ptp4l and associated config file handles the actual ptp
> > sourcing - configuring the phc's timestamping mechanisms and driving
> > ptp packets across the network, using time of day from a source.
> 
> It runs the PTP stack.

Just make sure you configure the correct data set in the config file and
(preferably) change it accordingly when you lose the 1PPS. Currently it's
not automated, but once you implement 1PPS monitoring, you can use
PMC protocol to change it.

> > Assumption #4: Prior to the NMEA stuff in ts2phc, I thought the way to
> > do this was to have a gps program (gpsd
> 
> I wouldn't recommend that program at all.
> 
> > or equivalent) capture the GPS
> > Time of Day, which is then used to set the local system clock. Then
> > phc2sys is used to push that from the system clock to the phc
> 
> No. That introduces unwanted time error.
> 
> > ("sys2phc" if you will), and then somehow either phc2sys or ts2phc
> > would align the least significant time digits (e.g. < 1 usec) using
> > the inbound PPS to tweak the PHC clock to be aligned to exactly 1
> > second, by reaching in to the PHC itself and stepping or frequency
> > tweaking.   Is that (was that?) correct?
> 
> No
> 
> > Assumption #5: Now that ts2phc has a NMEA option in it, does it now
> > set the ToD in the PHC directly?
> 
> Yes of course.  That is the whole point.
> 
> > If so, is phc2sys still used to push
> > that GPS-based (via NMEA) time that was pushed into the PHC by ts2phc
> > up to the system? Does it still need to be there for servo config?
> 
> No you can omit phc2sys altogether if you don't care about the local
> Linux system time.
> 
> You *can* use phc2sys to provide PHC -> CLOCK_REALTIME
> 
> HTH,
> Richard

Just make sure you don't use "generic" (aka CLOCK_REALTIME) time source
in ts2phc and phc2sys to transfer the time from the same PHC, as that
creates
the sync loop will end up bad.
The best way is, as Richard suggested, to use NMEA in ts2phc to set time
inside
the PHC, and use phc2sys to transfer that to system time.

Regards
Maciek
> 
> 
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] GPS + PPS PTP master - confusion about ts2phc, phc2sys, ptp4l options and interdependencies

[Richard C. <ric...@gm...>]

On Tue, Feb 22, 2022 at 01:50:39PM -0600, David Jedynak wrote:
> For use case orientation: Embedded system installed on a remote (no
> internet) infrastructure, receives GPS w/PPS, sets time from power-up
> (e.g. 1970) and acts as PTP grandmaster for the entire local
> infrastructure.  Hardware includes intel i210 with PPS input to SDP3
> (this cannot be changed, hardware already exists).  Occasional loss of
> GPS signal for a few seconds (< 10) at a time is expected, but no
> sophisticated clocks (e.g. TCXO or atomic) needed for better
> hold-over.
> 
> General query: With linuxptp 3.1 and newer (since ts2phc was added),
> it has become a bit confusing how to stitch together all the bits and
> how they interact. I see a caution in the ts2phc man page about
> sharing config files and overlapping options.  Seems like
> clarification is needed.  Are these assumptions below correct?

You do need to stitch the pieces together yourself, especially things
like monitoring GPS health/quality are yours to implement.

WRT configs files:  The warning is only there because each program
might need different options.  So the simple way is to provide each
program its own file.

> Assumption #1:  ts2phc and associated config file is how I configure
> the input (e.g. SDP3 on the i210) and some very basic options
> regarding pulse width.  ts2phc also has a NMEA option - stick a pin in
> that (see below).  ts2phc doesn't seem to have anything for actually
> configuring servo loops other than some step options.  Correct?

No.  You can choose the servo too.

> Is
> this why ts2phc run all by itself (no phc2sys running) has a bunch of
> (null) for clock related config items (e.g. "(null).clock_servo",
> "(null).pi_proportional_cont", etc.)? Am I missing something?

No, that is not the reason, but don't worry about the "null" debug
message.  It doesn't indicate an error.

> Assumption #2:  phc2sys and associated config file is how I configure
> servo loops (how do those interact w/ts2phc that's actually getting
> the pulses?)?

Well, each program has its own servo.

> It looks like phc2sys is how to link the phc to system
> time, and there are options for *sys* to set PHC Time of Day, or PHC
> to set *sys*, depending on the architecture's end goal and use case,
> right?

Yes.  But you don't want to let phc2sys change the PHC.  ts2phc will
take that job.

For a GPS GM, you don't actually need phc2sys at all.  It is merely a
nice-to-have when the Linux system time also follows the GPS.

> Assumption #3: ptp4l and associated config file handles the actual ptp
> sourcing - configuring the phc's timestamping mechanisms and driving
> ptp packets across the network, using time of day from a source.

It runs the PTP stack.

> Assumption #4: Prior to the NMEA stuff in ts2phc, I thought the way to
> do this was to have a gps program (gpsd

I wouldn't recommend that program at all.

> or equivalent) capture the GPS
> Time of Day, which is then used to set the local system clock.  Then
> phc2sys is used to push that from the system clock to the phc

No.  That introduces unwanted time error.

> ("sys2phc" if you will), and then somehow either phc2sys or ts2phc
> would align the least significant time digits (e.g. < 1 usec) using
> the inbound PPS to tweak the PHC clock to be aligned to exactly 1
> second, by reaching in to the PHC itself and stepping or frequency
> tweaking.   Is that (was that?) correct?

No

> Assumption #5: Now that ts2phc has a NMEA option in it, does it now
> set the ToD in the PHC directly?

Yes of course.  That is the whole point.

> If so, is phc2sys still used to push
> that GPS-based (via NMEA) time that was pushed into the PHC by ts2phc
> up to the system? Does it still need to be there for servo config?

No you can omit phc2sys altogether if you don't care about the local
Linux system time.

You *can* use phc2sys to provide PHC -> CLOCK_REALTIME


HTH,
Richard

Re: [Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Richard C. <ric...@gm...>]

On Tue, Mar 08, 2022 at 12:38:46PM +0100, Andre Puschmann wrote:
> Dear all,
> 
> we are trying to build a PTP grandmaster with linuxptp to provide sync
> signals to telco equipment.
> 
> So far we've only used the internal oscillators of the NIC for a bunch of
> cards, Intel based and also Microchip LAN7430.
> 
> I am now looking into disciplining the oscillators with an external PPS
> input to improve frequency stability. The EVB-LAN7430 eval kit has a PPS
> input exposed over a GPIO pin.
> 
> I was wondering if someone has used this successfully at all?

Yes, I would guess so.
 
> In general, what are the steps to set this up? Is this something managed in
> the NIC driver itself or do I have to (permanently) run the `ts2phc` to keep
> to PHC in sync?

You need to run ts2phc or similar.  In general, the NICs are dumb devices.
 
> Are there studies/measurements that compare the stability of such a system
> to e.g. commercial PTP grandmaster solutions?

I haven't seen any.  I've done my own reports showing, for example,
linuxptp + Intel210 + uBlox GPS radio performing comparably to
commercial GM solutions.

However, making a reliable GM product is quite a bit of work.  The PTP
software stack is only one piece of the puzzle.

HTH,
Richard

Re: [Linuxptp-users] Master offset is higher when ptp clock updates in every second

[Richard C. <ric...@gm...>]

On Tue, Mar 08, 2022 at 06:38:50PM +0530, Raj wrote:

> We used "clock_settime(clockid_t clockid, const struct timespec *tp)" to
> update the ptp clock in every second based on dsp time.

That is surely the wrong way.

> We have also tried to adjust the ptp clock frequency and step using
> "clock_adjtime()" every 1 second. However, we still observe higher master
> offset in slave.

Maybe your servo is unstable?

> Could you please suggest how to update ptp clock (/dev/ptp0) with 1_PPS
> (dsp time) without increasing master offset considerably.

Making a proper GM is a real engineering challenge.  The PTP software
stack is only one part of the puzzle.  We can't do your engineering
for you on this list.

Sorry,
Richard

[Linuxptp-users] Master offset is higher when ptp clock updates in every second

[Raj <mai...@gm...>]

Hi Team,

In our product there is a separate dsp core which is updated using 1_PPS.
The Linux application runs on a separate core and where we run ptp4l.
We are observing higher master offset when we update ptp clock(/dev/ptp0)
with dsp time in every second.
dsp time is read through linux application call which in turn will be read
from dsp.
We used "clock_settime(clockid_t clockid, const struct timespec *tp)" to
update the ptp clock in every second based on dsp time.
We have also tried to adjust the ptp clock frequency and step using
"clock_adjtime()" every 1 second. However, we still observe higher master
offset in slave.

Could you please suggest how to update ptp clock (/dev/ptp0) with 1_PPS
(dsp time) without increasing master offset considerably.

*Note: *PTP clock is initialized with dsp time once during boot up. After
this, If we do not update the ptp clock , then the master offset in slave
is always < 100ns

we are using linuxptp-3.1  &  Linux kernel 4.9.8

Salve Logs when ptp clock in master updates  every second:

[image: image.png]

Thanks,
Raj

[Linuxptp-users] Building a PTP grandmaster with disciplined oscillator

[Andre P. <and...@sr...>]

Dear all,

we are trying to build a PTP grandmaster with linuxptp to provide sync 
signals to telco equipment.

So far we've only used the internal oscillators of the NIC for a bunch 
of cards, Intel based and also Microchip LAN7430.

I am now looking into disciplining the oscillators with an external PPS 
input to improve frequency stability. The EVB-LAN7430 eval kit has a PPS 
input exposed over a GPIO pin.

I was wondering if someone has used this successfully at all?

In general, what are the steps to set this up? Is this something managed 
in the NIC driver itself or do I have to (permanently) run the `ts2phc` 
to keep to PHC in sync?

Are there studies/measurements that compare the stability of such a 
system to e.g. commercial PTP grandmaster solutions?

Thanks
Andre

Re: [Linuxptp-users] Need help for my issue in sending sync and follow_up packets using ptp4l

[Richard C. <ric...@gm...>]

On Fri, Mar 04, 2022 at 10:35:05PM +0530, Aditya Venu via Linuxptp-users wrote:

> I run another dpdk based application. The dpdk application routes all the
> data to *queue number 3* of my same HW. once I run this application, ptp4l
> stops sending sync follow_up and announce(I am checking in wireshark).
> 
> What can cause this issue? Why the ptp4l is stopping to send packets.

DPDK is a networking stack in user space that bypasses the Linux
kernel networking stack.  This is off topic for this list, and we
can't help you with it.

Sorry,
Richard

[Linuxptp-users] Need help for my issue in sending sync and follow_up packets using ptp4l

[Aditya V. <adi...@5g...>]

Hi,

I am using ptp4l application with my custom linux network driver for my
hardware which is connected to my server via PCIe.

The connection between my server and other system is direct i.e. no
switches in between.

-> When I insert my driver, the PCIe card attached to my server gets
detected as a NIC card which is visible on ifconfig output.
-> I am routing all the packets sent by ptp4l to *queue number 2 *of my HW
*.*
-> when I run ptp4l, all packets are going and also receiving delay_request
packet from the system which my server is connected to, and to which I am
responding with delay_response. I am able to achieve sync between my two
systems(ptp master and slave).

The problem comes when,
I run another dpdk based application. The dpdk application routes all the
data to *queue number 3* of my same HW. once I run this application, ptp4l
stops sending sync follow_up and announce(I am checking in wireshark).

What can cause this issue? Why the ptp4l is stopping to send packets.

Please help.

-Aditya

-- 


Disclaimer:- This footer text is to convey that this email is sent by one 
of the users of IITH. So, do not mark it as SPAM.

Re: [Linuxptp-users] GPS + PPS PTP master - confusion about ts2phc, phc2sys, ptp4l options and interdependencies

[Richard C. <ric...@gm...>]

On Mon, Feb 28, 2022 at 04:17:26PM -0600, David Jedynak wrote:
> Was hoping to see some responses on these questions.   Anything?

You are asking the right questions.

Kinda busy right now, so no time for adequate response.

Sorry,
Richard

Re: [Linuxptp-users] GPS + PPS PTP master - confusion about ts2phc, phc2sys, ptp4l options and interdependencies

[David J. <sil...@gm...>]

Was hoping to see some responses on these questions.   Anything?

On Tue, Feb 22, 2022 at 1:50 PM David Jedynak <sil...@gm...> wrote:
>
> For use case orientation: Embedded system installed on a remote (no
> internet) infrastructure, receives GPS w/PPS, sets time from power-up
> (e.g. 1970) and acts as PTP grandmaster for the entire local
> infrastructure.  Hardware includes intel i210 with PPS input to SDP3
> (this cannot be changed, hardware already exists).  Occasional loss of
> GPS signal for a few seconds (< 10) at a time is expected, but no
> sophisticated clocks (e.g. TCXO or atomic) needed for better
> hold-over.
>
> General query: With linuxptp 3.1 and newer (since ts2phc was added),
> it has become a bit confusing how to stitch together all the bits and
> how they interact. I see a caution in the ts2phc man page about
> sharing config files and overlapping options.  Seems like
> clarification is needed.  Are these assumptions below correct?
>
> Assumption #1:  ts2phc and associated config file is how I configure
> the input (e.g. SDP3 on the i210) and some very basic options
> regarding pulse width.  ts2phc also has a NMEA option - stick a pin in
> that (see below).  ts2phc doesn't seem to have anything for actually
> configuring servo loops other than some step options.  Correct?  Is
> this why ts2phc run all by itself (no phc2sys running) has a bunch of
> (null) for clock related config items (e.g. "(null).clock_servo",
> "(null).pi_proportional_cont", etc.)? Am I missing something?
>
> Assumption #2:  phc2sys and associated config file is how I configure
> servo loops (how do those interact w/ts2phc that's actually getting
> the pulses?)?  It looks like phc2sys is how to link the phc to system
> time, and there are options for *sys* to set PHC Time of Day, or PHC
> to set *sys*, depending on the architecture's end goal and use case,
> right?
>
> Assumption #3: ptp4l and associated config file handles the actual ptp
> sourcing - configuring the phc's timestamping mechanisms and driving
> ptp packets across the network, using time of day from a source.  See
> my question about direction in #2 (linux clocks as source or the time
> in the PHC as source)
>
> Assumption #4: Prior to the NMEA stuff in ts2phc, I thought the way to
> do this was to have a gps program (gpsd or equivalent) capture the GPS
> Time of Day, which is then used to set the local system clock.  Then
> phc2sys is used to push that from the system clock to the phc
> ("sys2phc" if you will), and then somehow either phc2sys or ts2phc
> would align the least significant time digits (e.g. < 1 usec) using
> the inbound PPS to tweak the PHC clock to be aligned to exactly 1
> second, by reaching in to the PHC itself and stepping or frequency
> tweaking.   Is that (was that?) correct?
>
> Assumption #5: Now that ts2phc has a NMEA option in it, does it now
> set the ToD in the PHC directly?  If so, is phc2sys still used to push
> that GPS-based (via NMEA) time that was pushed into the PHC by ts2phc
> up to the system? Does it still need to be there for servo config?
>
> Hopefully this can help drive clarity for myself or others.

Re: [Linuxptp-users] LinuxPTP in unicast

[Marco D. (SIDN) <mar...@si...>]

Hi Richard,

Op 25-02-2022 om 15:34 schreef Richard Cochran:

>> I created a unicast setup. It was an experiment to verify if I could make my
>> PTP-service more resilient against 'rogue' masters on the same VLAN that
>> (falsy) claim to be the best master.
> 
> A back actor on the LAN can easily spoof your unicast GM soruce
> address, so using unicast is does not mitigate that security risk.

True. This was more about 'accidental' failure, rather than malicious 
intend.

> It would be more development work to actively avoid multicast. It would not
> be impossible, but for me there would need to be a strong motivation
> to justify the effort.

I see.

Perhaps that time is better spend on implementing PTP V2.1 (IEEE 
1588–2019) Annex P in due time? ;-)

Thanks.

-- 
Marco

Re: [Linuxptp-users] ptp4l unicast losing sync after reaching s2 state

[Richard C. <ric...@gm...>]

On Fri, Feb 25, 2022 at 09:18:14AM +0100, Nils Fürste wrote:
 
> I attached some more detailed info. Any ideas what it can be or how I can
> debug this problem? Any advice is appreciated! Thanks in advance!

Look at the three call sites of:

	port_dispatch(p, EV_SYNCHRONIZATION_FAULT, 0);

> Client debug output: https://pastebin.com/D2f56EYN

There is a bunch of stuff in there NOT in mainline linuxptp:

ptp4l[14873.252]: US_TUNING_FREQ_COARSE
ptp4l[14873.252]: localdiff/freq_est_interval  1/10
ptp4l[14873.253]: t5-t1  1000035500 
ptp4l[14873.253]: t6-t2  1000035490 
ptp4l[14873.253]: ratio       +1 
ptp4l[14873.253]: freq       -10 
ptp4l[14873.253]: share_lock_status 0

I guess you hacked the servo, it returns SERVO_UNLOCKED inappropriately.

HTH,
Richard

Re: [Linuxptp-users] LinuxPTP in unicast

[Richard C. <ric...@gm...>]

On Fri, Feb 25, 2022 at 08:36:06AM +0100, Marco Davids (SIDN) via Linuxptp-users wrote:

> I created a unicast setup. It was an experiment to verify if I could make my
> PTP-service more resilient against 'rogue' masters on the same VLAN that
> (falsy) claim to be the best master.

A back actor on the LAN can easily spoof your unicast GM soruce
address, so using unicast is does not mitigate that security risk.
 
> But I was wondering; isn't it a bit strange for ptp4l to pick up multicast
> packets, even when it is configured to do unicast?

If the best master is multicast, then why not use it?

> Is this a bug or a feature?

(Take your pick ;^)

It would be more development work to actively avoid multicast.  This
would require changes to the very core of the program.  It would not
be impossible, but for me there would need to be a strong motivation
to justify the effort.

Thanks,
Richard