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

[Linuxptp-users] more Linux PTP documentation online

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

Dear list,

Just found this, authored by Intel:

   TSN Documentation Project for Linux

   https://tsn.readthedocs.io/index.html

It includes a chapter on synhcronization.

Just FYI.

Thanks,
Richard

[Linuxptp-users] Not able to observer SYNC, FOLLOW UP and ANNOUNCE packets in wireshark

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

Hi,
I cloned the master branch from https://github.com/openil/linuxptp
I ran the ptp application using sudo ./ptp4l -f configs/default.cfg -i
enp33s0 -2 -S -m. When I open the wireshark I am not able to observe sync,
follow_up and announce packets going from the application.

The output of uname -arn is
Linux amdserver 5.4.170-rt68 #1 SMP PREEMPT_RT Tue Jan 18 13:29:21 IST 2022
x86_64 x86_64 x86_64 GNU/Linux

But,

The same ptp4l code, with kernel 3.10 and RT patch with the same network
driver and hardware works fine. i.e. I am able to observe sync, follow_up,
announce, delay_request and delay_response packets in wireshark.

Can you please let me know how to resolve this issue?
let me know if I have to provide any further information.

Thanks and regards,
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] FYI - TX Timestamp Timeout Fix

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

On Thu, Jul 28, 2022 at 09:31:34AM +0200, Miroslav Lichvar wrote:
> On Wed, Jul 27, 2022 at 01:41:23PM -0700, Cliff Spradlin via Linuxptp-users wrote:
> > I just wanted to share the results of an investigation on TX timestamp
> > timeout problems my project has been experiencing. The tl;dr is that
> > the pfifo_fast qdisc suffers from data ordering bugs which can cause
> > outgoing packets to get forgotten / stuck in the outgoing buffer.
> > Those may have been fixed in newer kernel versions, but my solution
> > was to switch to the pfifo qdisc which uses much less sophisticated
> > codepaths.
> 
> Very interesting. Thanks for sharing.

Yes, and please also share on the netdev list (if you haven't already).

Thanks,
Richard

Re: [Linuxptp-users] ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

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

On Thu, Jul 28, 2022 at 04:38:52PM +0600, - - wrote:
> Yes, but it doesn't always work.
> I increased it to 100msec.

That driver, e1000e, uses a plain old "work" to process the Tx time
stamp.  Plain "work' runs at the lowest priority in Linux.  On a busy
system, even higher delays than 100 ms are possible.

The way to fix this is change the driver to use the PTP kworker thread
by moving the "work" code to the .do_aux_work callback.

Then you can set the kernel thread's schedule to SCHED_FIFO at high
priority using the chrt command.

Thanks,
Richard

Re: [Linuxptp-users] ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

[- - <art...@gm...>]

Yes, but it doesn't always work.
I increased it to 100msec.

Best regards,
Vyasheslav

ср, 27 июл. 2022 г. в 20:00, Richard Cochran <ric...@gm...>:

> On Wed, Jul 27, 2022 at 04:20:48PM +0600, - - wrote:
> > ptp4l[402.740]: timed out while polling for tx timestamp
> > ptp4l[402.740]: increasing tx_timestamp_timeout may correct this issue,
> but
>
> Did you try increasing tx_timestamp_timeout ?
>
> Thanks,
> Richard
>

Re: [Linuxptp-users] FYI - TX Timestamp Timeout Fix

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

On Wed, Jul 27, 2022 at 01:41:23PM -0700, Cliff Spradlin via Linuxptp-users wrote:
> I just wanted to share the results of an investigation on TX timestamp
> timeout problems my project has been experiencing. The tl;dr is that
> the pfifo_fast qdisc suffers from data ordering bugs which can cause
> outgoing packets to get forgotten / stuck in the outgoing buffer.
> Those may have been fixed in newer kernel versions, but my solution
> was to switch to the pfifo qdisc which uses much less sophisticated
> codepaths.

Very interesting. Thanks for sharing.

-- 
Miroslav Lichvar

[Linuxptp-users] FYI - TX Timestamp Timeout Fix

[Cliff S. <csp...@go...>]

I just wanted to share the results of an investigation on TX timestamp
timeout problems my project has been experiencing. The tl;dr is that
the pfifo_fast qdisc suffers from data ordering bugs which can cause
outgoing packets to get forgotten / stuck in the outgoing buffer.
Those may have been fixed in newer kernel versions, but my solution
was to switch to the pfifo qdisc which uses much less sophisticated
codepaths.

Our system:
- uses multi-TX-queue ethernet controllers (mostly Intel)
- has a many core NUMA architecture

What we found was that the ethernet driver and hardware was
essentially never at fault. Instead, packets were getting stuck in the
qdisc layer. Due to the consistent hashing load balancing scheme used
by default in Linux for multiple TX queues, it's possible to have a
busy link where one queue has almost all the traffic, and other queues
are either idle or nearly idle.

The issue is that sometimes Linux will forget that there's a packet to
transmit in the qdisc. For a queue that is relatively busy, packets
can experience little to no delay in transmission. But for idle or
nearly idle queues, the packet can get stuck until another packet is
sent on the same queue.

After discovering this, I found a series of memory ordering bugs over
the last few years involving "lockless" qdiscs. Here is just one
example: https://lore.kernel.org/all/202...@li.../

I'm not sure exactly which one we were experiencing, but the fact that
as recently as a month or two ago there have been new bugs fixed does
not give me confidence that all of the bugs are now fixed. So instead
I switched the default qdisc from pfifo_fast to pfifo, which is not a
lockless qdisc, using sysctl.conf.

This seems to have resolved nearly all the timeouts (from ~200 per day
to ~1 per 3 days). There is still that occasional blip that seems
attributable to the queueing layer; I'll have to do more investigation
to get to the bottom of that one.

Hope this helps!

-cliff

Re: [Linuxptp-users] ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

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

On Wed, Jul 27, 2022 at 04:20:48PM +0600, - - wrote:
> ptp4l[402.740]: timed out while polling for tx timestamp
> ptp4l[402.740]: increasing tx_timestamp_timeout may correct this issue, but

Did you try increasing tx_timestamp_timeout ?

Thanks,
Richard

[Linuxptp-users] ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

[- - <art...@gm...>]

Hi

I use linuxptp with the following settings:
master:
[global]
dataset_comparison G.8275.x
masterOnly 1
logAnnounceInterval -3
logSyncInterval -4
logMinDelayReqInterval -4
tx_timestamp_timeout 5
clockClass 6
clockAccuracy 0x21
offsetScaledLogVariance 0x4e5d
domainNumber 24
network_transport L2

slave:
[global]
dataset_comparison G.8275.x
logAnnounceInterval -3
logSyncInterval -4
logMinDelayReqInterval -4
tx_timestamp_timeout 5
domainNumber 24
network_transport L2

>From time to time there is a problem with ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
on the slave side:
ptp4l[427119.431]: rms 16303 max 43131 freq -16891 +/- 3592 delay 15888 +/-
2066
ptp4l[427120.550]: rms 10060 max 19890 freq -17425 +/- 2254 delay 16322 +/-
2517
ptp4l[427121.691]: rms 9415 max 23956 freq -18151 +/- 2154 delay 17059 +/-
594
ptp4l[427122.810]: rms 10578 max 20124 freq -17774 +/- 2426 delay 14718 +/-
2239
ptp4l[427123.472]: port 1: SLAVE to LISTENING on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[427123.472]: selected local clock 48df37.fffe.52407d as best master
ptp4l[427123.972]: selected local clock 48df37.fffe.52407d as best master
ptp4l[427124.460]: selected local clock 48df37.fffe.52407d as best master
ptp4l[427124.844]: selected local clock 48df37.fffe.52407d as best master
ptp4l[427125.248]: selected local clock 48df37.fffe.52407d as best master
ptp4l[427125.688]: selected local clock 48df37.fffe.52407d as best master
....

If I enable debugging on the master, I see an error:
ptp4l[402.740]: timed out while polling for tx timestamp
ptp4l[402.740]: increasing tx_timestamp_timeout may correct this issue, but
it is likely caused by a driver bug

The problem with the tx timestamp is not frequent, about once every 20
minutes.

You can help by answering a few questions:
1) Are ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES errors normal?
Or there shouldn't be any?
2) Maybe someone has encountered such errors and knows how to fix them?

To set the tx_timestamp I use the code
https://elixir.bootlin.com/linux/v4.9.322/source/drivers/net/ethernet/intel/e1000e/netdev.c#L1198
Best regards,
Vyasheslav

Re: [Linuxptp-users] 3 announce messages to switch LISTENING to UNCALIBRATED

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

On Mon, Jul 25, 2022 at 05:46:16PM +0000, Oleg Obleukhov via Linuxptp-users wrote:
> Hi team,
> I noticed that ptp4l expects 3 announce messages to arrive before switching LISTENING to UNCALIBRATED on RS_SLAVE.
> Can somebody point out why this is a requirement

See FOREIGN_MASTER_TIME_WINDOW and FOREIGN_MASTER_THRESHOLD in 1588.

> and if it’s possible to configure,

not really


Thanks,
Richard

Re: [Linuxptp-users] How to dynamically enable / disable PTP ports?

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

On Mon, Jul 25, 2022 at 11:43:52AM +0000, Osterried Markus (ETAS-DAP/XPC-Fe3) via Linuxptp-users wrote:

> Are there plans to implement these functionalities in ptp4l and pmc?

None.

> If not officially implemented, can anybody give hints how to implement it?
> How to create events EV_DESIGNATED_ENABLED / EV_DESIGNATED_DISABLED - or what else has to be done?

The code really was never designed for ports magically disappearing or
re-appearing again.  So you will have to carefully consider the side
effects, of which there might be many.

FWIW I gave up early on trying to make dynamic changes at run time (too many issues!)

Instead, I just do

    killall ptp4l; ptp4l --new-config-options

Thanks,
Richard

[Linuxptp-users] 3 announce messages to switch LISTENING to UNCALIBRATED

[Oleg O. <leo...@fb...>]

Hi team,
I noticed that ptp4l expects 3 announce messages to arrive before switching LISTENING to UNCALIBRATED on RS_SLAVE.
Can somebody point out why this is a requirement and if it’s possible to configure,
Best wishes,
Oleg.

[Linuxptp-users] How to dynamically enable / disable PTP ports?

[Osterried M. (ETAS-DAP/XPC-Fe3) <mar...@et...>]

Hi all,

I want to set up ptp4l on several network interfaces.
But I want to disable and enable PTP selectively on some interfaces at run time, i.e. without stopping ptp4l and restarting with different interface options.
The management messages ENABLE_PORT and DISABLE_PORT are not implemented in ptp4l and also not in pmc.

Are there plans to implement these functionalities in ptp4l and pmc?
If not officially implemented, can anybody give hints how to implement it?
How to create events EV_DESIGNATED_ENABLED / EV_DESIGNATED_DISABLED - or what else has to be done?

Are there any other ideas how to switch PTP ports on / off, e.g. faking link status to "up" / "down" (only for PTP, non-PTP traffic should not be affected)?


Many thanks
Regards
Markus

Re: [Linuxptp-users] ioctl SIOCSHWTSTAMP failed: Operation not supported

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

On Fri, Jul 22, 2022 at 10:46:33PM +0200, Mohammad wrote:
>    i am using patched ath9k driver to run wiFi-ptp
> 
>    linuxptp works with Software timestaming but with Hardware timestamping it
>    Shows this error.
> 
> 
> 
>    ptp4l[121.996]: ioctl SIOCSHWTSTAMP failed: Operation not supported

It's probably a bug in the patch that it presents both the SW and HW
timestamping capability.

But as was discussed in the previous thread, PTP over SW-timestamped
wifi will not work well.

-- 
Miroslav Lichvar

[Linuxptp-users] ioctl SIOCSHWTSTAMP failed: Operation not supported

[Mohammad <m.a...@gm...>]

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style></head><body lang=DE link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hello,</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>i am using patched ath9k driver to run wiFi-ptp</p><p class=MsoNormal>linuxptp works with Software timestaming but with Hardware timestamping it Shows this error.</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>ptp4l[121.996]: ioctl SIOCSHWTSTAMP failed: Operation not supported</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>thanks in Advance</p><p class=MsoNormal>Moh</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Gesendet von <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> für Windows</p><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>

Re: [Linuxptp-users] gPTP issues with ntpd

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

On Thu, Jul 21, 2022 at 02:13:29PM +0200, Jakub Raczyński wrote:
> My interpretation is based only on ntpshmmon tool - it clearly shows that ntpshm servo is only fed when PTP portState is set to Slave. So it is used only to write to the segment, but phc2sys clearly controls when it is done. Since ntpd does not communicate with phc2sys then whether it works or not is only based on phc2sys.

You said something about ntpd reset. I'm not sure what that is. If
there was something removing the segment (e.g. a script using ipcrm)
before phc2sys reverses the direction, it would create a new SHM, which
wouldn't be monitored by ntpshmmon started earlier.

> It seems you have great feature of phc2sys that allows to synchronize ntpshm servo in Slave state and use CLOCK_REALTIME as Master, yet you say like it does not exist. And again, I intend to use it that way. I am not trying to read anything from ntpshm.

ntpshm doesn't synchronize anything. It just provides data for another
process to synchronize the clock. ntpd can synchronize CLOCK_REALTIME,
but not a PHC, and even if it could, it wouldn't know when it should
switch.

You need two phc2sys instances.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] gPTP issues with ntpd

[Jakub R. <j.r...@el...>]

> 21.07.2022 13:06 Miroslav Lichvar <mli...@re...> wrote:
> 
>  
> On Thu, Jul 21, 2022 at 12:41:54PM +0200, Jakub Raczyński wrote:
> > > 21.07.2022 10:20 Miroslav Lichvar <mli...@re...> wrote:
> > > No, that's not correct. Try running the ntpshmmon tool from gpsd to
> > > see that phc2sys is writing new samples in both directions.
> > 
> > You are mistaken, I did try ntpshmmon and it does write to ntpshm only in one direction as Slave.
> 
> Well, that means there is something wrong with your setup.
> 
> > As such, since data is not written to ntpshm, I assume that phc2sys does select direction incorrectly after ntpd reset when significant offset was present. Seems like servo reset issue that does not update direction or sets it incorrectly. I will probably debug it in following days but I had hoped you could be of assistance.
> 
> Your interpretation is wrong.
> 
> If you looked at the code, you would see that the ntpshm servo is only
> writing to the segment. It doesn't know if there is anything reading
> that data, or what happens with it. ntpd cannot communicate with
> phc2sys over the SHM.

I fail to understand that, what could be wrong? I have one-to-one device connection where i only change priority1 of devices to select which should be Slave or Master.

My interpretation is based only on ntpshmmon tool - it clearly shows that ntpshm servo is only fed when PTP portState is set to Slave. So it is used only to write to the segment, but phc2sys clearly controls when it is done. Since ntpd does not communicate with phc2sys then whether it works or not is only based on phc2sys.

It seems you have great feature of phc2sys that allows to synchronize ntpshm servo in Slave state and use CLOCK_REALTIME as Master, yet you say like it does not exist. And again, I intend to use it that way. I am not trying to read anything from ntpshm.

Anyway, as said, I will look into it soon.

Best regards
Jakub Raczynski

Re: [Linuxptp-users] gPTP issues with ntpd

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

On Thu, Jul 21, 2022 at 12:41:54PM +0200, Jakub Raczyński wrote:
> > 21.07.2022 10:20 Miroslav Lichvar <mli...@re...> wrote:
> > No, that's not correct. Try running the ntpshmmon tool from gpsd to
> > see that phc2sys is writing new samples in both directions.
> 
> You are mistaken, I did try ntpshmmon and it does write to ntpshm only in one direction as Slave.

Well, that means there is something wrong with your setup.

> As such, since data is not written to ntpshm, I assume that phc2sys does select direction incorrectly after ntpd reset when significant offset was present. Seems like servo reset issue that does not update direction or sets it incorrectly. I will probably debug it in following days but I had hoped you could be of assistance.

Your interpretation is wrong.

If you looked at the code, you would see that the ntpshm servo is only
writing to the segment. It doesn't know if there is anything reading
that data, or what happens with it. ntpd cannot communicate with
phc2sys over the SHM.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] gPTP issues with ntpd

[Jakub R. <j.r...@el...>]

> 21.07.2022 10:20 Miroslav Lichvar <mli...@re...> wrote:
> 
>  
> On Wed, Jul 20, 2022 at 05:57:57PM +0200, Jakub Raczyński wrote:
> > So this setup seems to be correct and from the phc2sys log I sent previously it seems to be. So it seems that phc2sys is correctly writing timestamps to ntpshm only when it is Slave.
> 
> No, that's not correct. Try running the ntpshmmon tool from gpsd to
> see that phc2sys is writing new samples in both directions.

You are mistaken, I did try ntpshmmon and it does write to ntpshm only in one direction as Slave. When device switches to Master it stops writing to ntpshm. But from your reaction I assume this is unintended? Because it would work perfectly if not for the ntpd reset bug.

> 
> > The only problem is caused by ntpd reset - it starts synchronizing to PTP (ntpshm) even if it shouldn't as is it Master.
> 
> If you have multiple sources configured for ntpd, it could be
> rejecting the SHM as a falseticker when the TAI-UTC correction in
> phc2sys flips. On a restart/reset and depending on the polling
> intervals, it could temporarily select the SHM source for
> synchronization and later reject it again.
> 
> Try it with SHM as the only source. That should make it obvious
> that this cannot work.

I did and yet again it works and switches direction of synchronization perfectly. Yet again, goal is to achieve ntpshm as clock source in Slave state and CLOCK_REALTIME as Master clock for the network. I do not expect ntpshm to be two-way synchronization clock.

As such, since data is not written to ntpshm, I assume that phc2sys does select direction incorrectly after ntpd reset when significant offset was present. Seems like servo reset issue that does not update direction or sets it incorrectly. I will probably debug it in following days but I had hoped you could be of assistance.

Best regards
Jakub Raczynski

Re: [Linuxptp-users] gPTP issues with ntpd

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

On Wed, Jul 20, 2022 at 05:57:57PM +0200, Jakub Raczyński wrote:
> So this setup seems to be correct and from the phc2sys log I sent previously it seems to be. So it seems that phc2sys is correctly writing timestamps to ntpshm only when it is Slave.

No, that's not correct. Try running the ntpshmmon tool from gpsd to
see that phc2sys is writing new samples in both directions.

> The only problem is caused by ntpd reset - it starts synchronizing to PTP (ntpshm) even if it shouldn't as is it Master.

If you have multiple sources configured for ntpd, it could be
rejecting the SHM as a falseticker when the TAI-UTC correction in
phc2sys flips. On a restart/reset and depending on the polling
intervals, it could temporarily select the SHM source for
synchronization and later reject it again.

Try it with SHM as the only source. That should make it obvious
that this cannot work.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] ptp4l does not return delay response message

[Kevin C. <kev...@an...>]

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:DengXian;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@DengXian";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Miroslav,</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>No unfortunately I am not able to find another PTP master to try it out. But I stumbled across this article: <a href="https://github.com/ptpd/ptpd/issues/15">https://github.com/ptpd/ptpd/issues/15</a> It seems like older version of PTP4l might have this issue. The latest version that my distro (CentOS 7) has is version 2.0.2 and I am having issue installing the latest version. Something about the code needing C99 standard.</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><i>Best regards,<o:p></o:p></i></p><p class=MsoNormal><i>Kevin<o:p></o:p></i></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:mli...@re...">Miroslav Lichvar</a><br><b>Sent: </b>Monday, July 18, 2022 3:06 PM<br><b>To: </b><a href="mailto:kev...@an...">Kevin Choo</a><br><b>Cc: </b><a href="mailto:lin...@li...">lin...@li...</a><br><b>Subject: </b>Re: [Linuxptp-users] ptp4l does not return delay response message</p></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>On Fri, Jul 15, 2022 at 06:10:57PM +0800, Kevin Choo wrote:</p><p class=MsoNormal>&gt;    I am trying to test ptp implementation with ptp4l as the ptp master on a</p><p class=MsoNormal>&gt;    Linux pc and another ptp slave on evaluation board. Facing a weird issue</p><p class=MsoNormal>&gt;    where the ptp4l in master mode does not return delay response message when</p><p class=MsoNormal>&gt;    the slave is sending delay request message.</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Does it work with ptp4l as a client?</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>-- </p><p class=MsoNormal>Miroslav Lichvar</p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>

Re: [Linuxptp-users] Adding software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) capability to driver

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

On Wed, Jul 20, 2022 at 04:37:55PM +0000, Keller, Jacob E wrote:
> Right that's what I was afraid of: its basically just the same as software timestamping.

Actually it is way worse than SW timestamping.

WiFi has collisions.  Many of them.

Multicast frames have zero priority and are *not* re-transmitted when
corrupted by collision.

So the only way to do "regular" PTP (meaning without the FTM) is by
setting up unicast between the WiFi clients and the AP. 

Thanks,
Richard

Re: [Linuxptp-users] Adding software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) capability to driver

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Miroslav Lichvar <mli...@re...>
> Sent: Wednesday, July 20, 2022 1:04 AM
> To: Richard Cochran <ric...@gm...>
> Cc: Keller, Jacob E <jac...@in...>; linuxptp-
> us...@li...
> Subject: Re: [Linuxptp-users] Adding software-transmit
> (SOF_TIMESTAMPING_TX_SOFTWARE) capability to driver
> 
> On Tue, Jul 19, 2022 at 09:02:37PM -0700, Richard Cochran wrote:
> > > I am not sure how accurate a software timestamp for a wifi device would
> > > be, given the potential delay between timestamp and actual transmission.
> >
> > WiFi on Linux is never going to support PTP.  The issue is the closed
> > source radio firmware.  End of story.
> 
> I tested driver TX timestamping in the mt76 driver, where the firmware
> is supposed to be very simple, but IIRC it didn't make a noticeable
> difference when compared to user-space TX timestamping.
> 
> But if there is demand, I think we could see wireless chips with
> HW-timestamping support in future. If the stations can hear each
> other, maybe it wouldn't even be necessary for the access point to
> support PTP, like when using a cheap Ethernet hub instead of expensive
> switch with PTP support.
> 
> --
> Miroslav Lichvar

Right that's what I was afraid of: its basically just the same as software timestamping.

Thanks,
Jake

Re: [Linuxptp-users] gPTP issues with ntpd

[Jakub R. <j.r...@el...>]

<j.r...@el...> wrote:
> 
>  
> > 20.07.2022 15:23 Miroslav Lichvar <mli...@re...> write:
> > 
> >  
> > On Wed, Jul 20, 2022 at 03:12:39PM +0200, Jakub Raczyński wrote:
> > > phc2sys[2031.823]: lan1 sys offset      4870 s0 freq      +0 delay   1875
> > > phc2sys[2032.824]: lan1 sys offset      4915 s0 freq      +0 delay   1875
> > > phc2sys[2033.824]: lan1 sys offset      5011 s0 freq      +0 delay   1750
> > > phc2sys[2034.825]: port 360712.fffe.52efd6-1 changed state
> > > phc2sys[2034.826]: reconfiguring after port state change
> > > phc2sys[2034.828]: master clock not ready, waiting...
> > > phc2sys[2035.828]: port 360712.fffe.52efd6-1 changed state
> > > phc2sys[2035.830]: reconfiguring after port state change
> > > phc2sys[2035.831]: selecting CLOCK_REALTIME for synchronization
> > > phc2sys[2035.832]: selecting lan1 as the master clock
> > > phc2sys[2035.833]: CLOCK_REALTIME phc offset     -5136 s0 freq      +0 delay   1875
> > > phc2sys[2036.834]: CLOCK_REALTIME phc offset     -4435 s0 freq      +0 delay   1875
> > > 
> > > So, as mentioned "That is not expected to work" but kinda did or seemed like it. Would need more research and debugging what is actually happening inside both servos.
> > 
> > There is only one SHM segment and it's used by ntpd for
> > synchronization of the system clock. When phc2sys reverses the
> > direction, the offset will flip the sign, intending to synchronize the
> > PHC to the system clock, but ntpd will still be using the data it
> > receives to synchronize the system clock, which will cause a positive
> > feedback loop and the clock will be steered away, stepped, or ntpd
> > will give up depending on its configuration.
> > 
> > -- 
> > Miroslav Lichvar
> 
> Actually it didn't look like it - ntpd was giving up data from ntpshm instantly after switching to Master and started using ntpshm data right after switching to Slave. But as said, no idea what was going inside the servo.
> 
> But anyway, I will stick to the proposed workaround. Thanks again.
> 
> Jakub Raczynski
> 

I want to apologize for many emails, but I do not understand and expressed myself poorly.

When using phc2sys with: /usr/sbin/phc2sys -a -r -r -f /etc/ptp4l.cfg -E ntpshm -M 4
it mostly seems to work as I would expect - ntpd is not using data from PTP (ntpshm) when it is in Master state and us using data from ntpshm when Slave. The '-a -r -r' flag selects ntpshm as Slave servo only and CLOCK_REALTIME for Master.

So this setup seems to be correct and from the phc2sys log I sent previously it seems to be. So it seems that phc2sys is correctly writing timestamps to ntpshm only when it is Slave.

The only problem is caused by ntpd reset - it starts synchronizing to PTP (ntpshm) even if it shouldn't as is it Master. I have yet to debug whether it is phc2sys that does not set some flag for ntpd or if it is ntpd that clears some flag it probably shouldn't. But it seems like that phc2sys stays in mentioned "zombie servo" mode as it is synchronizing ntpshm to itself, even after killing ptp4l.

I am merely asking for advice why is it issue. Why is ntpshm being fed timestamps even if it is in Master state? Is it not directly controlled by phc2sys?
This should not require any workaround (although it would work, but seems a little excessive).

Best regards
Jakub Raczynski

Re: [Linuxptp-users] gPTP issues with ntpd

[Jakub R. <j.r...@el...>]

> 20.07.2022 15:23 Miroslav Lichvar <mli...@re...> write:
> 
>  
> On Wed, Jul 20, 2022 at 03:12:39PM +0200, Jakub Raczyński wrote:
> > phc2sys[2031.823]: lan1 sys offset      4870 s0 freq      +0 delay   1875
> > phc2sys[2032.824]: lan1 sys offset      4915 s0 freq      +0 delay   1875
> > phc2sys[2033.824]: lan1 sys offset      5011 s0 freq      +0 delay   1750
> > phc2sys[2034.825]: port 360712.fffe.52efd6-1 changed state
> > phc2sys[2034.826]: reconfiguring after port state change
> > phc2sys[2034.828]: master clock not ready, waiting...
> > phc2sys[2035.828]: port 360712.fffe.52efd6-1 changed state
> > phc2sys[2035.830]: reconfiguring after port state change
> > phc2sys[2035.831]: selecting CLOCK_REALTIME for synchronization
> > phc2sys[2035.832]: selecting lan1 as the master clock
> > phc2sys[2035.833]: CLOCK_REALTIME phc offset     -5136 s0 freq      +0 delay   1875
> > phc2sys[2036.834]: CLOCK_REALTIME phc offset     -4435 s0 freq      +0 delay   1875
> > 
> > So, as mentioned "That is not expected to work" but kinda did or seemed like it. Would need more research and debugging what is actually happening inside both servos.
> 
> There is only one SHM segment and it's used by ntpd for
> synchronization of the system clock. When phc2sys reverses the
> direction, the offset will flip the sign, intending to synchronize the
> PHC to the system clock, but ntpd will still be using the data it
> receives to synchronize the system clock, which will cause a positive
> feedback loop and the clock will be steered away, stepped, or ntpd
> will give up depending on its configuration.
> 
> -- 
> Miroslav Lichvar

Actually it didn't look like it - ntpd was giving up data from ntpshm instantly after switching to Master and started using ntpshm data right after switching to Slave. But as said, no idea what was going inside the servo.

But anyway, I will stick to the proposed workaround. Thanks again.

Jakub Raczynski