linuxptp-users Mailing List for linuxptp (Page 31)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Keller, J. E <jac...@in...> - 2022-03-25 00:23:10
|
> -----Original Message----- > From: Federico Murciano <Fed...@da...> > Sent: Thursday, March 24, 2022 3:02 AM > To: Keller, Jacob E <jac...@in...>; linuxptp- > us...@li... > Cc: Sebastian Peters <Seb...@da...> > Subject: AW: phc2sys not synchr. to right time and date > > Hi Jacob, > > Thank you for your answer. That is also what I thought, but the master and the > slave are connected directly via an Ethernet Cable. Is it possible that the slave > gets another Master clock from its second Ethernet interface, even if in the logs it > says selected best master clock with the ID of my desired Master? See in the logs > selected best master clock 04e548.fffe.230104: > And you've checked this master clock and it has the time you expect? Are you feeding that time into the master clock networking device using phc2sys? If you're using hardware timestamping, the clock on the device may not be in sync with the gettimeofday clock. Thanks, Jake |
|
From: Chris C. <680...@po...> - 2022-03-24 20:05:02
|
> I can also see in the Master devices this difference in its clocks: > from 32 seconds to 31 in the RTC time: > I did hwclock -w and still get this values None of that has anything to do with the PTP hardware clock (PHC) in the network controller. The system clock runs on the system processor, the PTP clock runs in the NIC. If you want the PHC to have the same time as system time, you have to put the system time into PHC. I specifically asked about phc2sys, and you replied with a response about hwclock, which is completely unrelated to PHC, so I think you misunderstood the clock topology in a standard PC type system running PTP. -- Chris Caudle |
|
From: Federico M. <Fed...@da...> - 2022-03-24 18:43:19
|
I can also see in the Master devices this difference in its clocks:
from 32 seconds to 31 in the RTC time:
I did hwclock -w and still get this values
root@MK6C:~# timedatectl
Local time: Thu 2022-03-24 18:41:32 UTC
Universal time: Thu 2022-03-24 18:41:32 UTC
RTC time: Thu 2022-03-24 18:41:31
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
root@MK6C:~# timedatectl
Local time: Thu 2022-03-24 18:41:32 UTC
Universal time: Thu 2022-03-24 18:41:32 UTC
RTC time: Thu 2022-03-24 18:41:32
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
Best regards,
Federico Murciano
M.Sc. Elektrotechnik - Telecommunications Engineer
fed...@da...
Tel. +49 (0) 30/314 -74 025 / Mob. +49 157 8642 4850
Future Communication Networks
DAI-Labor
Technische Universität Berlin
Fakultät IV – Elektrotechnik & Informatik Sekretariat TEL 14 Ernst-Reuter-Platz 7
10587 Berlin, Germany
http://www.dai-labor.de/
DAI-Labor - Distributed Artificial Intelligence Laboratory Chief Executive Director: Prof. Dr. Dr. h.c. Sahin Albayrak
________________________________________
Von: Chris Caudle <680...@po...>
Gesendet: Mittwoch, 23. März 2022 18:33
An: lin...@li...
Betreff: Re: [Linuxptp-users] phc2sys not synchr. to right time and date
> From: Federico Murciano <Fed...@da...>
> Subject: [Linuxptp-users] phc2sys not synchr. to right time and date
> Message-ID: <164...@da...>
> sudo phc2sys -s enp0s31f6 -O 0 -m
That is on the slave computer?
What is the phc2sys options and output messages on the master computer
showing transfer of system time to phc time?
--
Chris Caudle
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Federico M. <Fed...@da...> - 2022-03-24 18:38:44
|
Hi all, Now I managed to solve the 2018 issue by just using the default conf installed with linuxptp for the master. I have 3 different Master slave setups where the slaves are sending messages between another which include the timestamp from the Transmission time to calculate the latency in the reception. Now the problem I am facing is that for two of the setups, I see coherent latency values but for the other one, I see some negative latency values, which implies that that Master slave setup has a different and wrong clock than the two others. All 3 setups are identical and are taking the source from a GPS signal. The only thing that is different is that in this setup, the computer with GPS device is switched on from longer time. I can remotely reboot it but not switch off from electricity and switch on again. Is it possible that this is the issue and it is syncing to a not uptaded clock? With the two that I can manually connect to electricity values are quite good. Thanks a lot in advance for the answers. Best regards, Federico Murciano M.Sc. Elektrotechnik - Telecommunications Engineer fed...@da... Tel. +49 (0) 30/314 -74 025 / Mob. +49 157 8642 4850 Future Communication Networks DAI-Labor Technische Universität Berlin Fakultät IV – Elektrotechnik & Informatik Sekretariat TEL 14 Ernst-Reuter-Platz 7 10587 Berlin, Germany http://www.dai-labor.de/ DAI-Labor - Distributed Artificial Intelligence Laboratory Chief Executive Director: Prof. Dr. Dr. h.c. Sahin Albayrak ________________________________________ Von: Vladimir Oltean <ol...@gm...> Gesendet: Donnerstag, 24. März 2022 19:09 An: ch...@ch... Cc: lin...@li... Betreff: Re: [Linuxptp-users] phc2sys not synchr. to right time and date On Thu, Mar 24, 2022 at 09:14:08AM -0500, Chris Caudle wrote: > On Thu, March 24, 2022 5:02 am, > lin...@li... wrote: > > From: Federico Murciano <Fed...@da...> > > Subject: Re: [Linuxptp-users] phc2sys not synchr. to right time and > > date > > Message-ID: <164...@da...> > > > Thank you for your answer. Yes this is in the slave computer. In the > > master computer I only execute the following, which is working for my > > other setup (with replicated master and slave devices): > > > > cat ptp.cfg > > [global] > > tx_timestamp_timeout 10 > > step_threshold 1 > > > > sudo ptp4l -A -i eth0 -m -f ptp.cfg > > Then what process is expected to set the time for the PHC? That seems to > be a missing step in your configuration. Perhaps the better question is > why does the other setup ever work? > > -- > Chris Caudle (there might be other reasons why his setup is working, but) Some kernel Ethernet drivers have a bad habit of writing the current (UTC) system time (derived from the battery-backed RTC) into the PHC current (TAI) time at boot. You're off by 37 seconds, but hey, at least it's 2022, so the time _must_ be right! https://elixir.bootlin.com/linux/latest/source/drivers/ptp/ptp_qoriq.c#L504 _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Vladimir O. <ol...@gm...> - 2022-03-24 18:09:57
|
On Thu, Mar 24, 2022 at 09:14:08AM -0500, Chris Caudle wrote: > On Thu, March 24, 2022 5:02 am, > lin...@li... wrote: > > From: Federico Murciano <Fed...@da...> > > Subject: Re: [Linuxptp-users] phc2sys not synchr. to right time and > > date > > Message-ID: <164...@da...> > > > Thank you for your answer. Yes this is in the slave computer. In the > > master computer I only execute the following, which is working for my > > other setup (with replicated master and slave devices): > > > > cat ptp.cfg > > [global] > > tx_timestamp_timeout 10 > > step_threshold 1 > > > > sudo ptp4l -A -i eth0 -m -f ptp.cfg > > Then what process is expected to set the time for the PHC? That seems to > be a missing step in your configuration. Perhaps the better question is > why does the other setup ever work? > > -- > Chris Caudle (there might be other reasons why his setup is working, but) Some kernel Ethernet drivers have a bad habit of writing the current (UTC) system time (derived from the battery-backed RTC) into the PHC current (TAI) time at boot. You're off by 37 seconds, but hey, at least it's 2022, so the time _must_ be right! https://elixir.bootlin.com/linux/latest/source/drivers/ptp/ptp_qoriq.c#L504 |
|
From: Chris C. <680...@po...> - 2022-03-24 14:47:00
|
On Thu, March 24, 2022 5:02 am, lin...@li... wrote: > From: Federico Murciano <Fed...@da...> > Subject: Re: [Linuxptp-users] phc2sys not synchr. to right time and > date > Message-ID: <164...@da...> > Thank you for your answer. Yes this is in the slave computer. In the > master computer I only execute the following, which is working for my > other setup (with replicated master and slave devices): > > cat ptp.cfg > [global] > tx_timestamp_timeout 10 > step_threshold 1 > > sudo ptp4l -A -i eth0 -m -f ptp.cfg Then what process is expected to set the time for the PHC? That seems to be a missing step in your configuration. Perhaps the better question is why does the other setup ever work? -- Chris Caudle |
|
From: Federico M. <Fed...@da...> - 2022-03-24 10:02:40
|
Hi Jacob,
Thank you for your answer. That is also what I thought, but the master and the slave are connected directly via an Ethernet Cable. Is it possible that the slave gets another Master clock from its second Ethernet interface, even if in the logs it says selected best master clock with the ID of my desired Master? See in the logs selected best master clock 04e548.fffe.230104:
sudo ptp4l -A -i eth0 -m -f ptp.cfg
ptp4l[101681.741]: selected /dev/ptp0 as PTP clock
ptp4l[101681.742]: driver changed our HWTSTAMP options
ptp4l[101681.742]: tx_type 1 not 1
ptp4l[101681.742]: rx_filter 1 not 12
ptp4l[101681.742]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 1: link up
ptp4l[101689.067]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[101689.067]: selected best master clock 04e548.fffe.230104
ptp4l[101689.067]: assuming the grand master role
Slave-1
linuxptp.cfg file:
[global]
clientOnly 1
delay_mechanism Auto
network_transport UDPv4
#time_stamping hardware # for the HW-timestamping slave
#time_stamping software # for the SW-timestamping slave
step_threshold 1.0
utc_offset 37
# make sure our slave clock is never elected as master
priority1 255
priority2 255
[enp0s31f6]
sudo ptp4l -s -f linuxptp.cfg -m
ptp4l[105105.227]: selected /dev/ptp0 as PTP clock
ptp4l[105105.228]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.228]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.894]: port 1: new foreign master 04e548.fffe.230104-1
ptp4l[105109.894]: selected best master clock 04e548.fffe.230104
Als ungelesen markieren
Sebastian Peters
Do 24.03.2022 10:21
-------- Forwarded Message --------
Subject: RE: phc2sys not synchr. to right time and date
Date: Wed, 23 Mar 2022 17:35:03 +0000
From: Keller, Jacob E <jac...@in...>
To: Federico Murciano <Fed...@da...>, lin...@li... <lin...@li...>
CC: Sebastian Peters <Seb...@da...>
Keller, Jacob E <jac...@in...>
Mi 23.03.2022 18:39
-----Original Message----- From: Federico Murciano <Fed...@da...> Sent: Wednesday, March 23, 2022 10:13 AM To: lin...@li... Cc: Sebastian Peters <Seb...@da...> Subject: Re: [Linuxptp-users] phc2sys
Federico Murciano <Fed...@da...>
Mi 23.03.2022 18:15
Hey agai, I also tried using linux services instead, which has a more detailed configuration file but stills the date is the wrong one: edge2@dai-edge2:~$ systemctl status ptp4l.service ● ptp4l.service - Precision Time Protocol (PTP) service Loaded: loaded
Federico Murciano
Mi 23.03.2022 18:13
Hey agai, I also tried using linux services instead, which has a more detailed configuration file but stills the date is the wrong one: edge2@dai-edge2:~$ systemctl status ptp4l.service ● ptp4l.service - Precision Time Protocol (PTP) service Loaded: loaded
Federico Murciano <Fed...@da...>
Mi 23.03.2022 18:11
Hello everyone, I am trying to sync different Ubuntu computers to the ptp master clock from another device connected to each of them. The setup is very easy: Ubuntu Laptop as Slave <-> Ubuntu device with GPS signal as Master The problem is that for one system,
ANTWORTENALLEN ANTWORTENWEITERLEITEN
Als ungelesen markieren
Federico Murciano
Mi 23.03.2022 17:53
Gesendete Elemente
An:
lin...@li...;
Cc:
Sebastian Peters;
Hello everyone,
I am trying to sync different Ubuntu computers to the ptp master clock from another device connected to each of them.
The setup is very easy:
Ubuntu Laptop as Slave <-> Ubuntu device with GPS signal as Master
The problem is that for one system, everything is working right, but for other system with the same setup, when the date is updated it is set to a day in 2018, which is obviously not the case. I also had some offset issues that I believe are solved already by using phc2sys with the -O 0 option (0seconds offset).
Here are the steps that I follow:
Master
ptp.cfg file:
[global]
tx_timestamp_timeout 10
step_threshold 1
user@MK6C:~$ timedatectl
Local time: Wed 2022-03-23 16:38:27 UTC
Universal time: Wed 2022-03-23 16:38:27 UTC
RTC time: Wed 2022-03-23 16:38:28
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
sudo ptp4l -A -i eth0 -m -f ptp.cfg
ptp4l[101681.741]: selected /dev/ptp0 as PTP clock
ptp4l[101681.742]: driver changed our HWTSTAMP options
ptp4l[101681.742]: tx_type 1 not 1
ptp4l[101681.742]: rx_filter 1 not 12
ptp4l[101681.742]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 1: link up
ptp4l[101689.067]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[101689.067]: selected best master clock 04e548.fffe.230104
ptp4l[101689.067]: assuming the grand master role
Slave-1
linuxptp.cfg file:
[global]
clientOnly 1
delay_mechanism Auto
network_transport UDPv4
#time_stamping hardware # for the HW-timestamping slave
#time_stamping software # for the SW-timestamping slave
step_threshold 1.0
utc_offset 37
# make sure our slave clock is never elected as master
priority1 255
priority2 255
[enp0s31f6]
sudo ptp4l -s -f linuxptp.cfg -m
ptp4l[105105.227]: selected /dev/ptp0 as PTP clock
ptp4l[105105.228]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.228]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.894]: port 1: new foreign master 04e548.fffe.230104-1
ptp4l[105109.894]: selected best master clock 04e548.fffe.230104
Best regards,
Federico Murciano
M.Sc. Elektrotechnik - Telecommunications Engineer
fed...@da...
Tel. +49 (0) 30/314 -74 025 / Mob. +49 157 8642 4850
Future Communication Networks
DAI-Labor
Technische Universität Berlin
Fakultät IV – Elektrotechnik & Informatik Sekretariat TEL 14 Ernst-Reuter-Platz 7
10587 Berlin, Germany
http://www.dai-labor.de/
DAI-Labor - Distributed Artificial Intelligence Laboratory Chief Executive Director: Prof. Dr. Dr. h.c. Sahin Albayrak
________________________________________
Von: Keller, Jacob E <jac...@in...>
Gesendet: Mittwoch, 23. März 2022 18:35
An: Federico Murciano; lin...@li...
Cc: Sebastian Peters
Betreff: RE: phc2sys not synchr. to right time and date
> -----Original Message-----
> From: Federico Murciano <Fed...@da...>
> Sent: Wednesday, March 23, 2022 10:13 AM
> To: lin...@li...
> Cc: Sebastian Peters <Seb...@da...>
> Subject: Re: [Linuxptp-users] phc2sys not synchr. to right time and date
>
> edge2@dai-edge2:~$ timedatectl
>
> Local time: Mon 2018-01-29 20:53:33 UTC
>
> Universal time: Mon 2018-01-29 20:53:33 UTC
>
> RTC time: Mon 2018-01-29 20:53:33
>
> Time zone: Etc/UTC (UTC, +0000)
>
> System clock synchronized: yes
>
> NTP service: inactive
>
> RTC in local TZ: no
>
>
>
> This is working correctly in one setup but in other two I get this weird 2018 date
> set.
>
>
The PTP algorithm is going to accept the date time from whatever wins the Best Master Clock algorithm. Do you know what clock on the network is the master clock? I suspect that clock is misconfigured.
Thanks,
Jake
|
|
From: Federico M. <Fed...@da...> - 2022-03-24 09:53:33
|
Hi Chris, Thank you for your answer. Yes this is in the slave computer. In the master computer I only execute the following, which is working for my other setup (with replicated master and slave devices): cat ptp.cfg [global] tx_timestamp_timeout 10 step_threshold 1 sudo ptp4l -A -i eth0 -m -f ptp.cfg Best regards, Federico Murciano M.Sc. Elektrotechnik - Telecommunications Engineer fed...@da... Tel. +49 (0) 30/314 -74 025 / Mob. +49 157 8642 4850 Future Communication Networks DAI-Labor Technische Universität Berlin Fakultät IV – Elektrotechnik & Informatik Sekretariat TEL 14 Ernst-Reuter-Platz 7 10587 Berlin, Germany http://www.dai-labor.de/ DAI-Labor - Distributed Artificial Intelligence Laboratory Chief Executive Director: Prof. Dr. Dr. h.c. Sahin Albayrak ________________________________________ Von: Chris Caudle <680...@po...> Gesendet: Mittwoch, 23. März 2022 18:33 An: lin...@li... Betreff: Re: [Linuxptp-users] phc2sys not synchr. to right time and date > From: Federico Murciano <Fed...@da...> > Subject: [Linuxptp-users] phc2sys not synchr. to right time and date > Message-ID: <164...@da...> > sudo phc2sys -s enp0s31f6 -O 0 -m That is on the slave computer? What is the phc2sys options and output messages on the master computer showing transfer of system time to phc time? -- Chris Caudle _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Chris C. <680...@po...> - 2022-03-23 18:04:21
|
> From: Federico Murciano <Fed...@da...> > Subject: [Linuxptp-users] phc2sys not synchr. to right time and date > Message-ID: <164...@da...> > sudo phc2sys -s enp0s31f6 -O 0 -m That is on the slave computer? What is the phc2sys options and output messages on the master computer showing transfer of system time to phc time? -- Chris Caudle |
|
From: Keller, J. E <jac...@in...> - 2022-03-23 17:39:18
|
> -----Original Message----- > From: Federico Murciano <Fed...@da...> > Sent: Wednesday, March 23, 2022 10:13 AM > To: lin...@li... > Cc: Sebastian Peters <Seb...@da...> > Subject: Re: [Linuxptp-users] phc2sys not synchr. to right time and date > > edge2@dai-edge2:~$ timedatectl > > Local time: Mon 2018-01-29 20:53:33 UTC > > Universal time: Mon 2018-01-29 20:53:33 UTC > > RTC time: Mon 2018-01-29 20:53:33 > > Time zone: Etc/UTC (UTC, +0000) > > System clock synchronized: yes > > NTP service: inactive > > RTC in local TZ: no > > > > This is working correctly in one setup but in other two I get this weird 2018 date > set. > > The PTP algorithm is going to accept the date time from whatever wins the Best Master Clock algorithm. Do you know what clock on the network is the master clock? I suspect that clock is misconfigured. Thanks, Jake |
|
From: Federico M. <Fed...@da...> - 2022-03-23 17:13:34
|
Hey agai,
I also tried using linux services instead, which has a more detailed configuration file but stills the date is the wrong one:
edge2@dai-edge2:~$ systemctl status ptp4l.service
● ptp4l.service - Precision Time Protocol (PTP) service
Loaded: loaded (/lib/systemd/system/ptp4l.service; disabled; vendor preset: enabled)
Active: active (running) since Mon 2018-01-29 21:13:04 UTC; 9s ago
Docs: man:ptp4l
Main PID: 97589 (ptp4l)
Tasks: 1 (limit: 38293)
Memory: 472.0K
CGroup: /system.slice/ptp4l.service
└─97589 /usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i enp2s0
Jan 29 21:13:04 dai-edge2 ptp4l[97589]: [107547.002] port 1: INITIALIZING to LISTENING on INIT_COMPLETE
Jan 29 21:13:04 dai-edge2 ptp4l[97589]: [107547.002] port 0: INITIALIZING to LISTENING on INIT_COMPLETE
Jan 29 21:13:05 dai-edge2 ptp4l[97589]: [107548.047] port 1: new foreign master 04e548.fffe.230104-1
Jan 29 21:13:09 dai-edge2 ptp4l[97589]: [107552.048] selected best master clock 04e548.fffe.230104
Jan 29 21:13:09 dai-edge2 ptp4l[97589]: [107552.048] running in a temporal vortex
Jan 29 21:13:09 dai-edge2 ptp4l[97589]: [107552.048] port 1: LISTENING to UNCALIBRATED on RS_SLAVE
Jan 29 21:13:11 dai-edge2 ptp4l[97589]: [107554.048] master offset -1208 s0 freq +21717 path delay 225
Jan 29 21:13:12 dai-edge2 ptp4l[97589]: [107555.048] master offset -1263 s2 freq +21662 path delay 233
Jan 29 21:13:12 dai-edge2 ptp4l[97589]: [107555.048] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
Jan 29 21:13:13 dai-edge2 ptp4l[97589]: [107556.048] master offset -1247 s2 freq +20415 path delay 233
edge2@dai-edge2:~$ systemctl status phc2sys.service
● phc2sys.service - Synchronize system clock or PTP hardware clock (PHC)
Loaded: loaded (/lib/systemd/system/phc2sys.service; disabled; vendor preset: enabled)
Active: active (running) since Mon 2018-01-29 21:13:10 UTC; 11s ago
Docs: man:phc2sys
Main PID: 97611 (phc2sys)
Tasks: 1 (limit: 38293)
Memory: 352.0K
CGroup: /system.slice/phc2sys.service
└─97611 /usr/sbin/phc2sys -w -s enp2s0
Jan 29 21:13:12 dai-edge2 phc2sys[97611]: [107555.845] Waiting for ptp4l...
Jan 29 21:13:13 dai-edge2 phc2sys[97611]: [107556.846] CLOCK_REALTIME phc offset 6353 s0 freq +29047 delay 5570
Jan 29 21:13:14 dai-edge2 phc2sys[97611]: [107557.847] CLOCK_REALTIME phc offset 5973 s2 freq +28667 delay 5601
Jan 29 21:13:15 dai-edge2 phc2sys[97611]: [107558.847] CLOCK_REALTIME phc offset 6381 s2 freq +35048 delay 5604
Jan 29 21:13:16 dai-edge2 phc2sys[97611]: [107559.847] CLOCK_REALTIME phc offset 483 s2 freq +31064 delay 5556
Jan 29 21:13:17 dai-edge2 phc2sys[97611]: [107560.848] CLOCK_REALTIME phc offset -1381 s2 freq +29345 delay 5571
Jan 29 21:13:18 dai-edge2 phc2sys[97611]: [107561.848] CLOCK_REALTIME phc offset -1559 s2 freq +28753 delay 5560
Jan 29 21:13:19 dai-edge2 phc2sys[97611]: [107562.849] CLOCK_REALTIME phc offset -1136 s2 freq +28708 delay 5561
Jan 29 21:13:20 dai-edge2 phc2sys[97611]: [107563.849] CLOCK_REALTIME phc offset -659 s2 freq +28845 delay 5609
Jan 29 21:13:21 dai-edge2 phc2sys[97611]: [107564.850] CLOCK_REALTIME phc offset -361 s2 freq +28945 delay 5578
edge2@dai-edge2:~$ timedatectl
Local time: Mon 2018-01-29 21:14:54 UTC
Universal time: Mon 2018-01-29 21:14:54 UTC
RTC time: Mon 2018-01-29 21:14:54
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: inactive
Best regards,
Federico Murciano
M.Sc. Elektrotechnik - Telecommunications Engineer
fed...@da...
Tel. +49 (0) 30/314 -74 025 / Mob. +49 157 8642 4850
Future Communication Networks
DAI-Labor
Technische Universität Berlin
Fakultät IV – Elektrotechnik & Informatik Sekretariat TEL 14 Ernst-Reuter-Platz 7
10587 Berlin, Germany
http://www.dai-labor.de/
DAI-Labor - Distributed Artificial Intelligence Laboratory Chief Executive Director: Prof. Dr. Dr. h.c. Sahin Albayrak
________________________________________
Von: Federico Murciano <Fed...@da...>
Gesendet: Mittwoch, 23. März 2022 17:53
An: lin...@li...
Cc: Sebastian Peters
Betreff: [Linuxptp-users] phc2sys not synchr. to right time and date
Hello everyone,
I am trying to sync different Ubuntu computers to the ptp master clock from another device connected to each of them.
The setup is very easy:
Ubuntu Laptop as Slave <-> Ubuntu device with GPS signal as Master
The problem is that for one system, everything is working right, but for other system with the same setup, when the date is updated it is set to a day in 2018, which is obviously not the case. I also had some offset issues that I believe are solved already by using phc2sys with the -O 0 option (0seconds offset).
Here are the steps that I follow:
Master
ptp.cfg file:
[global]
tx_timestamp_timeout 10
step_threshold 1
user@MK6C:~$ timedatectl
Local time: Wed 2022-03-23 16:38:27 UTC
Universal time: Wed 2022-03-23 16:38:27 UTC
RTC time: Wed 2022-03-23 16:38:28
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
sudo ptp4l -A -i eth0 -m -f ptp.cfg
ptp4l[101681.741]: selected /dev/ptp0 as PTP clock
ptp4l[101681.742]: driver changed our HWTSTAMP options
ptp4l[101681.742]: tx_type 1 not 1
ptp4l[101681.742]: rx_filter 1 not 12
ptp4l[101681.742]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 1: link up
ptp4l[101689.067]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[101689.067]: selected best master clock 04e548.fffe.230104
ptp4l[101689.067]: assuming the grand master role
Slave-1
linuxptp.cfg file:
[global]
clientOnly 1
delay_mechanism Auto
network_transport UDPv4
#time_stamping hardware # for the HW-timestamping slave
#time_stamping software # for the SW-timestamping slave
step_threshold 1.0
utc_offset 37
# make sure our slave clock is never elected as master
priority1 255
priority2 255
[enp0s31f6]
sudo ptp4l -s -f linuxptp.cfg -m
ptp4l[105105.227]: selected /dev/ptp0 as PTP clock
ptp4l[105105.228]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.228]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.894]: port 1: new foreign master 04e548.fffe.230104-1
ptp4l[105109.894]: selected best master clock 04e548.fffe.230104
ptp4l[105109.894]: running in a temporal vortex
ptp4l[105109.895]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[105111.895]: master offset -18633 s0 freq +24199 path delay 267
ptp4l[105112.895]: master offset -18834 s2 freq +23998 path delay 267
ptp4l[105112.895]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[105113.895]: master offset -18827 s2 freq +5171 path delay 267
ptp4l[105114.895]: master offset -22 s2 freq +18328 path delay 262
ptp4l[105115.895]: master offset 5676 s2 freq +24019 path delay 262
ptp4l[105116.895]: master offset 5669 s2 freq +25715 path delay 257
ptp4l[105117.895]: master offset 3948 s2 freq +25695 path delay 262
ptp4l[105118.895]: master offset 2246 s2 freq +25177 path delay 267
ptp4l[105119.895]: master offset 1066 s2 freq +24671 path delay 267
ptp4l[105120.895]: master offset 363 s2 freq +24288 path delay 288
ptp4l[105121.895]: master offset 79 s2 freq +24113 path delay 273
ptp4l[105122.895]: master offset -36 s2 freq +24021 path delay 273
ptp4l[105123.895]: master offset -63 s2 freq +23984 path delay 268
edge2@dai-edge2:~$ timedatectl
Local time: Mon 2018-01-29 20:52:35 UTC
Universal time: Mon 2018-01-29 20:52:35 UTC
RTC time: Mon 2018-01-29 20:52:35
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
sudo phc2sys -s enp0s31f6 -O 0 -m
edge2@dai-edge2:~$ sudo phc2sys -s enp2s0 -O -36 -m
phc2sys[105266.195]: CLOCK_REALTIME phc offset -72 s0 freq +31297 delay 5547
phc2sys[105267.196]: CLOCK_REALTIME phc offset -131 s2 freq +31238 delay 5503
phc2sys[105268.196]: CLOCK_REALTIME phc offset -70 s2 freq +31168 delay 5574
phc2sys[105269.197]: CLOCK_REALTIME phc offset 17 s2 freq +31234 delay 5481
phc2sys[105270.197]: CLOCK_REALTIME phc offset 102 s2 freq +31324 delay 5588
phc2sys[105271.197]: CLOCK_REALTIME phc offset 60 s2 freq +31313 delay 5590
phc2sys[105272.198]: CLOCK_REALTIME phc offset 58 s2 freq +31329 delay 5559
phc2sys[105273.198]: CLOCK_REALTIME phc offset 22 s2 freq +31310 delay 5569
^Cphc2sys[105274.179]: CLOCK_REALTIME phc offset -66 s2 freq +31229 delay 5546
edge2@dai-edge2:~$ timedatectl
Local time: Mon 2018-01-29 20:53:33 UTC
Universal time: Mon 2018-01-29 20:53:33 UTC
RTC time: Mon 2018-01-29 20:53:33
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
This is working correctly in one setup but in other two I get this weird 2018 date set.
Am I missing something? Any help would be very appreciated. Thanks in advance!
Best regards,
Federico Murciano
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Federico M. <Fed...@da...> - 2022-03-23 17:09:23
|
Hello everyone,
I am trying to sync different Ubuntu computers to the ptp master clock from another device connected to each of them.
The setup is very easy:
Ubuntu Laptop as Slave <-> Ubuntu device with GPS signal as Master
The problem is that for one system, everything is working right, but for other system with the same setup, when the date is updated it is set to a day in 2018, which is obviously not the case. I also had some offset issues that I believe are solved already by using phc2sys with the -O 0 option (0seconds offset).
Here are the steps that I follow:
Master
ptp.cfg file:
[global]
tx_timestamp_timeout 10
step_threshold 1
user@MK6C:~$ timedatectl
Local time: Wed 2022-03-23 16:38:27 UTC
Universal time: Wed 2022-03-23 16:38:27 UTC
RTC time: Wed 2022-03-23 16:38:28
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
sudo ptp4l -A -i eth0 -m -f ptp.cfg
ptp4l[101681.741]: selected /dev/ptp0 as PTP clock
ptp4l[101681.742]: driver changed our HWTSTAMP options
ptp4l[101681.742]: tx_type 1 not 1
ptp4l[101681.742]: rx_filter 1 not 12
ptp4l[101681.742]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[101681.743]: port 1: link up
ptp4l[101689.067]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[101689.067]: selected best master clock 04e548.fffe.230104
ptp4l[101689.067]: assuming the grand master role
Slave-1
linuxptp.cfg file:
[global]
clientOnly 1
delay_mechanism Auto
network_transport UDPv4
#time_stamping hardware # for the HW-timestamping slave
#time_stamping software # for the SW-timestamping slave
step_threshold 1.0
utc_offset 37
# make sure our slave clock is never elected as master
priority1 255
priority2 255
[enp0s31f6]
sudo ptp4l -s -f linuxptp.cfg -m
ptp4l[105105.227]: selected /dev/ptp0 as PTP clock
ptp4l[105105.228]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.228]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[105105.894]: port 1: new foreign master 04e548.fffe.230104-1
ptp4l[105109.894]: selected best master clock 04e548.fffe.230104
ptp4l[105109.894]: running in a temporal vortex
ptp4l[105109.895]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[105111.895]: master offset -18633 s0 freq +24199 path delay 267
ptp4l[105112.895]: master offset -18834 s2 freq +23998 path delay 267
ptp4l[105112.895]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[105113.895]: master offset -18827 s2 freq +5171 path delay 267
ptp4l[105114.895]: master offset -22 s2 freq +18328 path delay 262
ptp4l[105115.895]: master offset 5676 s2 freq +24019 path delay 262
ptp4l[105116.895]: master offset 5669 s2 freq +25715 path delay 257
ptp4l[105117.895]: master offset 3948 s2 freq +25695 path delay 262
ptp4l[105118.895]: master offset 2246 s2 freq +25177 path delay 267
ptp4l[105119.895]: master offset 1066 s2 freq +24671 path delay 267
ptp4l[105120.895]: master offset 363 s2 freq +24288 path delay 288
ptp4l[105121.895]: master offset 79 s2 freq +24113 path delay 273
ptp4l[105122.895]: master offset -36 s2 freq +24021 path delay 273
ptp4l[105123.895]: master offset -63 s2 freq +23984 path delay 268
edge2@dai-edge2:~$ timedatectl
Local time: Mon 2018-01-29 20:52:35 UTC
Universal time: Mon 2018-01-29 20:52:35 UTC
RTC time: Mon 2018-01-29 20:52:35
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
sudo phc2sys -s enp0s31f6 -O 0 -m
edge2@dai-edge2:~$ sudo phc2sys -s enp2s0 -O -36 -m
phc2sys[105266.195]: CLOCK_REALTIME phc offset -72 s0 freq +31297 delay 5547
phc2sys[105267.196]: CLOCK_REALTIME phc offset -131 s2 freq +31238 delay 5503
phc2sys[105268.196]: CLOCK_REALTIME phc offset -70 s2 freq +31168 delay 5574
phc2sys[105269.197]: CLOCK_REALTIME phc offset 17 s2 freq +31234 delay 5481
phc2sys[105270.197]: CLOCK_REALTIME phc offset 102 s2 freq +31324 delay 5588
phc2sys[105271.197]: CLOCK_REALTIME phc offset 60 s2 freq +31313 delay 5590
phc2sys[105272.198]: CLOCK_REALTIME phc offset 58 s2 freq +31329 delay 5559
phc2sys[105273.198]: CLOCK_REALTIME phc offset 22 s2 freq +31310 delay 5569
^Cphc2sys[105274.179]: CLOCK_REALTIME phc offset -66 s2 freq +31229 delay 5546
edge2@dai-edge2:~$ timedatectl
Local time: Mon 2018-01-29 20:53:33 UTC
Universal time: Mon 2018-01-29 20:53:33 UTC
RTC time: Mon 2018-01-29 20:53:33
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
This is working correctly in one setup but in other two I get this weird 2018 date set.
Am I missing something? Any help would be very appreciated. Thanks in advance!
Best regards,
Federico Murciano
|
|
From: Keller, J. E <jac...@in...> - 2022-03-18 15:16:14
|
On 3/18/2022 3:40 AM, ps...@we... wrote: > Hello, > > I have a problem with the high of the calculated path delay. I am using > hardware timestamping and thought I get values less than 20ns. But i > have values over 7.8µs is that normal? > I have also tested the usecase with an i210, there I got 250ns, but > these are also quite high. > I think others have mentioned this. It sounds like a symptom of EEE. Have you disabled that? I believe i219 has EEE support and it may be enabled by default. You can check it with --show-eee and configure it with --set-eee This is the Energy Efficient Ethernet, which can impact things such as the path delay because the packet is delayed in hardware due to the low power link. I believe the i219 captures the timestamp in the MAC before it sends it to the PHY, so the low power mode in the PHY introduces a significant delay there. > Questions: > 1. why are the values of i219 and i210 so different? what does the path > delay depend on The path delay is a measure of the time it takes between Tx timestamp on one end to Rx timestamp on the other end. It depends on the network in between. Do you have a (non-TC) switch in between? Typically as long as the path delay is stable, it doesn't cause a significant issue whether its higher or lower. It does depend on the NIC design, because it depends on where in the transmit and receive pipelines the timestamps happen. Its possible that some difference in how the devices capture timestamps results in the larger gap. The i219 may be taking the timestamp earlier in the process of sending a packet, or later in the process of receiving the packet. > 2. if it depends only on the NIC, where can I find out which NIC is the > best one for hardware time stamping, which keywords in the datasheet are > important? Unfortunately this is very difficult to determine. The data sheets do have some discussion of the PTP functionality and information. I don't know if they have any detailed schematic data for this though. I typically recommend the i210 device based on the igb driver, as it had a focus on supporting 802.1AS features and has had a strong track record. > 3. Is there a driver problem or is it possible to change something at > the ptp-files to get better values? > For path delay? not unless the driver is buggy. The path delay is calculated by measuring the time it takes for a delay request packet to transit the network. > NIC: I2019-V rev 21 > driver: e1000e - 3.8.4-NAPI > Kernel:5.4.0-104-generic > > output of: ethtool -T enp0s31f6: > Time stamping parameters for enp0s31f6: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) > ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) > > I use a i219-Notebook with following command as a slave: sudo ptp4l -P > -H -l 7 -i enp0s31f6 -m -s > The "Master"-command is simmiliar just with another interface and > without -s. > Output: > ptp4l[183917.707]: selected best master clock 70ff76.fffe.1dea84 > ptp4l[183917.707]: port 1 (enp0s31f6): LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[183918.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183918.445]: delay filtered 7358 raw 7319 > ptp4l[183918.707]: master offset 239333 s0 freq +45884 path delay > 7858 > ptp4l[183919.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183919.445]: delay filtered 7358 raw 7422 > ptp4l[183919.707]: master offset 239368 s1 freq +45919 path delay > 7858 > ptp4l[183920.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183920.445]: delay filtered 7349 raw 7345 > ptp4l[183920.708]: master offset -464 s2 freq +45455 path delay > 7849 > ptp4l[183920.708]: port 1 (enp0s31f6): UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[183921.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183921.445]: delay filtered 7349 raw 7336 > ptp4l[183921.709]: master offset -485 s2 freq +45295 path delay > 7849 > ptp4l[183922.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183922.446]: delay filtered 7349 raw 7365 > ptp4l[183922.709]: master offset 27 s2 freq +45661 path delay > 7849 > ptp4l[183923.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183923.446]: delay filtered 7340 raw 7330 > ptp4l[183923.709]: master offset 137 s2 freq +45779 path delay > 7840 > You'll notice that even with a 7 usec path delay, it still manages to adjust the offset and adjust the clock. You could verify the offset from master using the Net sync monitor feature to ensure the offset is as-reported. Hope this helps explain things. Thanks, Jake > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Joseph M. <jos...@gm...> - 2022-03-18 13:21:54
|
I did try to disable the EEE feature, but it didn't help. I agree it does sounds exactly like a EEE feature. בתאריך יום ו׳, 18 במרץ 2022, 14:33, מאת Vladimir Oltean <ol...@gm... >: > On Fri, Mar 18, 2022 at 02:19:24PM +0200, Joseph Matan wrote: > > Hi, > > > > I don't have an answer to your question, but I can share from my > experience > > that I'm familiar with this. I even posted a similar question a year or > so > > ago. > > I also tried to open a ticket in Intel Customer Service but nothing good > > came through. > > Maybe the e1000e developers community would have an idea (but I didn't > try > > to ask there). > > > > My problem with the i219 NIC was that with no traffic the path delay was > > around ~7 or 8 usec (as you mentioned), but in intervals of high load of > > traffic the path delay decreased significantly to something like 800 nsec > > (0.8 usec). > > These significant changes in the path delay between 8 usec to 0.8 usec > > caused me lots of accurecy troubles... (and I didn't use any switch > between > > my master and slave). > > However, from the tests I was doing, the i210 doesn't suffer from this > > behaviour. > > Intel Customer Service didn't know to answer if this is a bug or perhaps > a > > feature that can be switched off/on. > > > > Hope it helped somehow... > > Joseph > > Not sure if you've exhausted this option with Intel support, but this > sounds like the typical signature of what Energy Efficient Ethernet > would do to PTP. > |
|
From: Vladimir O. <ol...@gm...> - 2022-03-18 12:33:39
|
On Fri, Mar 18, 2022 at 02:19:24PM +0200, Joseph Matan wrote: > Hi, > > I don't have an answer to your question, but I can share from my experience > that I'm familiar with this. I even posted a similar question a year or so > ago. > I also tried to open a ticket in Intel Customer Service but nothing good > came through. > Maybe the e1000e developers community would have an idea (but I didn't try > to ask there). > > My problem with the i219 NIC was that with no traffic the path delay was > around ~7 or 8 usec (as you mentioned), but in intervals of high load of > traffic the path delay decreased significantly to something like 800 nsec > (0.8 usec). > These significant changes in the path delay between 8 usec to 0.8 usec > caused me lots of accurecy troubles... (and I didn't use any switch between > my master and slave). > However, from the tests I was doing, the i210 doesn't suffer from this > behaviour. > Intel Customer Service didn't know to answer if this is a bug or perhaps a > feature that can be switched off/on. > > Hope it helped somehow... > Joseph Not sure if you've exhausted this option with Intel support, but this sounds like the typical signature of what Energy Efficient Ethernet would do to PTP. |
|
From: Joseph M. <jos...@gm...> - 2022-03-18 12:19:42
|
Hi, I don't have an answer to your question, but I can share from my experience that I'm familiar with this. I even posted a similar question a year or so ago. I also tried to open a ticket in Intel Customer Service but nothing good came through. Maybe the e1000e developers community would have an idea (but I didn't try to ask there). My problem with the i219 NIC was that with no traffic the path delay was around ~7 or 8 usec (as you mentioned), but in intervals of high load of traffic the path delay decreased significantly to something like 800 nsec (0.8 usec). These significant changes in the path delay between 8 usec to 0.8 usec caused me lots of accurecy troubles... (and I didn't use any switch between my master and slave). However, from the tests I was doing, the i210 doesn't suffer from this behaviour. Intel Customer Service didn't know to answer if this is a bug or perhaps a feature that can be switched off/on. Hope it helped somehow... Joseph On Fri, Mar 18, 2022 at 12:44 PM <ps...@we...> wrote: > Hello, > > I have a problem with the high of the calculated path delay. I am using > hardware timestamping and thought I get values less than 20ns. But i have > values over 7.8µs is that normal? > I have also tested the usecase with an i210, there I got 250ns, but these > are also quite high. > > Questions: > 1. why are the values of i219 and i210 so different? what does the path > delay depend on? > 2. if it depends only on the NIC, where can I find out which NIC is the > best one for hardware time stamping, which keywords in the datasheet are > important? > 3. Is there a driver problem or is it possible to change something at the > ptp-files to get better values? > > NIC: I2019-V rev 21 > driver: e1000e - 3.8.4-NAPI > Kernel:5.4.0-104-generic > > output of: ethtool -T enp0s31f6: > Time stamping parameters for enp0s31f6: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) > ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) > > I use a i219-Notebook with following command as a slave: sudo ptp4l -P -H > -l 7 -i enp0s31f6 -m -s > The "Master"-command is simmiliar just with another interface and without > -s. > Output: > ptp4l[183917.707]: selected best master clock 70ff76.fffe.1dea84 > ptp4l[183917.707]: port 1 (enp0s31f6): LISTENING to UNCALIBRATED on > RS_SLAVE > ptp4l[183918.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183918.445]: delay filtered 7358 raw 7319 > ptp4l[183918.707]: master offset 239333 s0 freq +45884 path delay > 7858 > ptp4l[183919.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183919.445]: delay filtered 7358 raw 7422 > ptp4l[183919.707]: master offset 239368 s1 freq +45919 path delay > 7858 > ptp4l[183920.444]: port 1 (enp0s31f6): delay timeout > ptp4l[183920.445]: delay filtered 7349 raw 7345 > ptp4l[183920.708]: master offset -464 s2 freq +45455 path delay > 7849 > ptp4l[183920.708]: port 1 (enp0s31f6): UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[183921.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183921.445]: delay filtered 7349 raw 7336 > ptp4l[183921.709]: master offset -485 s2 freq +45295 path delay > 7849 > ptp4l[183922.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183922.446]: delay filtered 7349 raw 7365 > ptp4l[183922.709]: master offset 27 s2 freq +45661 path delay > 7849 > ptp4l[183923.445]: port 1 (enp0s31f6): delay timeout > ptp4l[183923.446]: delay filtered 7340 raw 7330 > ptp4l[183923.709]: master offset 137 s2 freq +45779 path delay > 7840 > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: <ps...@we...> - 2022-03-18 10:40:55
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hello,</div> <div> </div> <div>I have a problem with the high of the calculated path delay. I am using hardware timestamping and thought I get values less than 20ns. But i have values over 7.8µs is that normal?<br/> I have also tested the usecase with an i210, there I got 250ns, but these are also quite high.</div> <div> </div> <div>Questions:</div> <div>1. why are the values of i219 and i210 so different? what does the path delay depend on?<br/> 2. if it depends only on the NIC, where can I find out which NIC is the best one for hardware time stamping, which keywords in the datasheet are important? <br/> 3. Is there a driver problem or is it possible to change something at the ptp-files to get better values?</div> <div> </div> <div>NIC: I2019-V rev 21<br/> driver: e1000e - 3.8.4-NAPI</div> <div>Kernel:5.4.0-104-generic</div> <div> </div> <div>output of: ethtool -T enp0s31f6:<br/> Time stamping parameters for enp0s31f6:<br/> Capabilities:<br/> hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)<br/> software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)<br/> hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)<br/> software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)<br/> software-system-clock (SOF_TIMESTAMPING_SOFTWARE)<br/> hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)<br/> PTP Hardware Clock: 0<br/> Hardware Transmit Timestamp Modes:<br/> off (HWTSTAMP_TX_OFF)<br/> on (HWTSTAMP_TX_ON)<br/> Hardware Receive Filter Modes:<br/> none (HWTSTAMP_FILTER_NONE)<br/> all (HWTSTAMP_FILTER_ALL)<br/> ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)<br/> ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)<br/> ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)<br/> ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)<br/> ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)<br/> ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)<br/> ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)<br/> ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)<br/> ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)</div> <div><br/> I use a i219-Notebook with following command as a slave: sudo ptp4l -P -H -l 7 -i enp0s31f6 -m -s<br/> The "Master"-command is simmiliar just with another interface and without -s.</div> <div>Output:<br/> ptp4l[183917.707]: selected best master clock 70ff76.fffe.1dea84<br/> ptp4l[183917.707]: port 1 (enp0s31f6): LISTENING to UNCALIBRATED on RS_SLAVE<br/> ptp4l[183918.444]: port 1 (enp0s31f6): delay timeout<br/> ptp4l[183918.445]: delay filtered 7358 raw 7319<br/> ptp4l[183918.707]: master offset 239333 s0 freq +45884 path delay 7858<br/> ptp4l[183919.444]: port 1 (enp0s31f6): delay timeout<br/> ptp4l[183919.445]: delay filtered 7358 raw 7422<br/> ptp4l[183919.707]: master offset 239368 s1 freq +45919 path delay 7858<br/> ptp4l[183920.444]: port 1 (enp0s31f6): delay timeout<br/> ptp4l[183920.445]: delay filtered 7349 raw 7345<br/> ptp4l[183920.708]: master offset -464 s2 freq +45455 path delay 7849<br/> ptp4l[183920.708]: port 1 (enp0s31f6): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED<br/> ptp4l[183921.445]: port 1 (enp0s31f6): delay timeout<br/> ptp4l[183921.445]: delay filtered 7349 raw 7336<br/> ptp4l[183921.709]: master offset -485 s2 freq +45295 path delay 7849<br/> ptp4l[183922.445]: port 1 (enp0s31f6): delay timeout<br/> ptp4l[183922.446]: delay filtered 7349 raw 7365<br/> ptp4l[183922.709]: master offset 27 s2 freq +45661 path delay 7849<br/> ptp4l[183923.445]: port 1 (enp0s31f6): delay timeout<br/> ptp4l[183923.446]: delay filtered 7340 raw 7330<br/> ptp4l[183923.709]: master offset 137 s2 freq +45779 path delay 7840</div> <div><br/> </div></div></body></html> |
|
From: ramesh t <ram...@ya...> - 2022-03-17 17:27:16
|
Hello Miroslav Lichvar, Tried as suggested, observed below error. ptp4l: [806352.926] clockcheck: clock jumped backward or running slower than expected! So set sanity_freq_limit to 0, but still observing errors: ptp4l: [806913.536] timed out while polling for tx timestamp ptp4l: [806913.536] increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l: [806913.536] port 2: send sync failed ptp4l: [806913.536] port 2: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l: [806913.922] port 1: received link status notification ptp4l: [806913.922] port 2: received link status notification ptp4l: [806913.922] port 2: link down ptp4l: [806913.922] port 2: received link status notification DOWN ptp4l: [806913.922] selected local clock 40a6b7.fffe.0da261 as best master ptp4l: [806913.922] port 1: assuming the grand master role ptp4l: [806913.922] port 1: SLAVE to GRAND_MASTER on RS_GRAND_MASTER ptp4l: [806913.922] selected best master clock 000580.fffe.07cc8a ptp4l: [806913.922] updating UTC offset to 37 ptp4l: [806913.922] port 1: GRAND_MASTER to UNCALIBRATED on RS_SLAVE Not sure if any other parameter needs to be changed. regards, Ramesh On Thursday, March 17, 2022, 05:23:15 PM GMT+5:30, ramesh t via Linuxptp-users <lin...@li...> wrote: Hello Miroslav Lichvar, Please find the value of ptp config as per 8275.1 standards. logAnnounceInterval -3 announceReceiptTimeout 3 We can't increase beyond the above values. regards, Ramesh On Thursday, March 17, 2022, 04:10:38 PM GMT+5:30, Miroslav Lichvar <mli...@re...> wrote: On Wed, Mar 16, 2022 at 06:23:23PM +0000, ramesh t via Linuxptp-users wrote: > ptp4l: [704774.649] port 1: announce timeout > ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM. > > Can you please suggest how we can resolve this issue? Maybe some optimization could be implemented in the kernel to shorten that time. I don't know why it takes so long. What is your logAnnounceInterval and announceReceiptTimeout? Could they be increased? -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: ramesh t <ram...@ya...> - 2022-03-17 11:49:26
|
Hello Miroslav Lichvar, Please find the value of ptp config as per 8275.1 standards. logAnnounceInterval -3 announceReceiptTimeout 3 We can't increase beyond the above values. regards, Ramesh On Thursday, March 17, 2022, 04:10:38 PM GMT+5:30, Miroslav Lichvar <mli...@re...> wrote: On Wed, Mar 16, 2022 at 06:23:23PM +0000, ramesh t via Linuxptp-users wrote: > ptp4l: [704774.649] port 1: announce timeout > ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM. > > Can you please suggest how we can resolve this issue? Maybe some optimization could be implemented in the kernel to shorten that time. I don't know why it takes so long. What is your logAnnounceInterval and announceReceiptTimeout? Could they be increased? -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2022-03-17 10:40:52
|
On Wed, Mar 16, 2022 at 06:23:23PM +0000, ramesh t via Linuxptp-users wrote: > ptp4l: [704774.649] port 1: announce timeout > ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM. > > Can you please suggest how we can resolve this issue? Maybe some optimization could be implemented in the kernel to shorten that time. I don't know why it takes so long. What is your logAnnounceInterval and announceReceiptTimeout? Could they be increased? -- Miroslav Lichvar |
|
From: ramesh t <ram...@ya...> - 2022-03-16 18:23:32
|
Hello, Have ptp4l running in BC mode providing clock to connected TestUnits (via port 2) and syncing clock from BC/GM (via port 1) Did few more iterations of testing (ptp4l in BC mode) by doing ifconfig down. Observing PTP4l reporting below error in port 1 connected to BC/GM ptp4l: [704774.649] port 1: announce timeout ptp4l: [704774.649] port 1: SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES On debugging further, when port 2 is configured for down state, we call raw_close in port_disable, to close the open FDs. This closure is taking around 600ms to 800ms. This in turn impacts handling on accounce packets on port1 connected to BC/GM. Can you please suggest how we can resolve this issue? regards, Ramesh |
|
From: Keller, J. E <jac...@in...> - 2022-03-16 16:29:50
|
> -----Original Message----- > From: Miroslav Lichvar <mli...@re...> > Sent: Wednesday, March 16, 2022 2:32 AM > To: Marco Davids (SIDN) <mar...@si...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Building a PTP grandmaster with disciplined > oscillator > > On Tue, Mar 15, 2022 at 04:06:31PM +0100, Marco Davids (SIDN) via Linuxptp- > users wrote: > > I have a setup with an interface being a PTP client (HW timestamping, a nice > > Meinberg GM and such) and phc2sys supplying time from it to another > > interface's PHC in the same server. > > > > Is there anything to be said about the accuracy/precision on the second > > interface's PHC with this approach? > > The accuracy and stability is impacted by asymmetry and jitter of the > PCIe latency. Half of the delay printed by phc2sys gives you an upper > bound, assuming in one direction the latency is zero and the other > direction taking all the delay, similarly to the root delay in NTP. > > There is a PCIe feature supported on some HW called Precision Time > Measurement (PTM) that uses HW timestamping of PCIe messages and > should at least in theory significantly improve the accuracy and > stability, but the support in the kernel doesn't seem to be finished > yet. > The challenge here is that PCIe PTM also requires device support. I know some variants of the ice hardware support this, but typically only the ones that are built onto motherboards. > If you need best performance, you should synchronize the PHC through > the system clock. That is, instead of > > phc2sys -s eth0 -c eth1 > > use > > phc2sys -s eth0 -c CLOCK_REALTIME > phc2sys -s CLOCK_REALTIME -c eth1 > > Ideally, the NICs should be the same model. That will cancel out > asymmetries in the HW timestamping errors, which can be larger than > the PCIe asymmetry. > This approach allows you to take advantage of PCIe PTM as well, if its supported. The other approach does not allow any use of PCIe PTM since its directly tied to using the platform clock. > -- > Miroslav Lichvar > > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Miroslav L. <mli...@re...> - 2022-03-16 09:32:18
|
On Tue, Mar 15, 2022 at 04:06:31PM +0100, Marco Davids (SIDN) via Linuxptp-users wrote: > I have a setup with an interface being a PTP client (HW timestamping, a nice > Meinberg GM and such) and phc2sys supplying time from it to another > interface's PHC in the same server. > > Is there anything to be said about the accuracy/precision on the second > interface's PHC with this approach? The accuracy and stability is impacted by asymmetry and jitter of the PCIe latency. Half of the delay printed by phc2sys gives you an upper bound, assuming in one direction the latency is zero and the other direction taking all the delay, similarly to the root delay in NTP. There is a PCIe feature supported on some HW called Precision Time Measurement (PTM) that uses HW timestamping of PCIe messages and should at least in theory significantly improve the accuracy and stability, but the support in the kernel doesn't seem to be finished yet. If you need best performance, you should synchronize the PHC through the system clock. That is, instead of phc2sys -s eth0 -c eth1 use phc2sys -s eth0 -c CLOCK_REALTIME phc2sys -s CLOCK_REALTIME -c eth1 Ideally, the NICs should be the same model. That will cancel out asymmetries in the HW timestamping errors, which can be larger than the PCIe asymmetry. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2022-03-15 23:32:08
|
On Tue, Mar 15, 2022 at 04:06:31PM +0100, Marco Davids (SIDN) via Linuxptp-users wrote: > I have a setup with an interface being a PTP client (HW timestamping, a nice > Meinberg GM and such) and phc2sys supplying time from it to another > interface's PHC in the same server. > > Is there anything to be said about the accuracy/precision on the second > interface's PHC with this approach? The answer is, "it depends". The timestamps used by phc2sys are SW, and a busy system might preempt phc2sys a just the wrong times, causing time error. You a can mitigate by using a preempt_rt kernel and giving phc2sys sched_fifo priority. You can force artificial system load using `hackbench` `stress` and friends. You can characterize your performance by measuring end to end, like from a PPS from a client on the second port back to the Meinberg's PPS. HTH, Richard |
|
From: Marco D. (SIDN) <mar...@si...> - 2022-03-15 16:40:12
|
Richard, Op 15-03-2022 om 15:37 schreef Richard Cochran: > 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. This one triggered a question; I have a setup with an interface being a PTP client (HW timestamping, a nice Meinberg GM and such) and phc2sys supplying time from it to another interface's PHC in the same server. Is there anything to be said about the accuracy/precision on the second interface's PHC with this approach? -- Marco |
27 messages has been excluded from this view by a project administrator.
