linuxptp-users Mailing List for linuxptp (Page 40)
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: Brooks, J. <Jas...@Al...> - 2021-11-04 20:22:28
|
Hello,
I am trying to build a proof-of-concept systems that will listen for ptp and then serve ntp, but I seem to have a problem: the clock on the system does not seem to get set by ptp, and therefore the clock drifts. I have a test system that uses multiple internet ntp sources and this one: this one's offset keeps growing.
I don't see any sign in /var/log/messages that the clock is trying to be slewed or stepped.
This is a centos 7 system running under vmware 6.7 (no precision clock available). It is using the ethernet device "e1000" to allow the ethernet software timestamping for both transmit and receive. There is no /dev/ptp device so phc2sys is not running.
There are two grandmaster ptp feeds coming into this system.
Upgrading to vmware 7 is not in the cards at the moment, but I might get to play with sr-iov.
I am running ptp4l as: "/usr/sbin/ptp4l -f /etc/ptp4l.conf -i ens34 -l 5 -S"
Ptp4l is configured with the following values altered in the /etc/ptp4l.conf:
domainNumber == 44
slaveOnly == 1
ntpd is running with a minimal config:
server 127.127.1.0
fudge 127.127.1.0 stratum 0
pmc "GET time_status_np" shows that ptp4l is synced with the grand master
sending: GET TIME_STATUS_NP
005056.fffe.be1c0f-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 0
ingress_time 1636054977549001043
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 0080ea.fffe.842b60
pmc -u -b 0 -f /etc/ptp4l.conf "GET current_data_set"
sending: GET CURRENT_DATA_SET
005056.fffe.be1c0f-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET
stepsRemoved 1
offsetFromMaster 0.0
meanPathDelay 0.0
Jason Brooks
Senior Cloud Infrastructure Engineer
Infrastructure and Engineering Services
Allstream
[id:image001.jpg@01D2AD47.F9210620]<http://www.allstream.com/>
NOTICE - CONFIDENTIAL INFORMATION This communication is the property of Allstream and may contain confidential or privileged information. If you have received this communication in error, please promptly notify the sender by reply e-mail, do not disseminate, distribute, copy or use the information contained in this communication, and destroy all copies of the communication and any attachments.
AVIS - RENSEIGNEMENTS CONFIDENTIELS Cette communication est la propri?t? d'Allstream et peut contenir des renseignements confidentiels ou privil?gi?s. Si vous avez re?u cette communication par erreur, veuillez informer rapidement l'exp?diteur en r?pondant par courriel, ne pas diffuser, distribuer, copier ou utiliser les renseignements contenus dans la pr?sente communication, et d?truire toutes les copies de la communication et ses pi?ces jointes.
|
|
From: Keller, J. E <jac...@in...> - 2021-11-03 19:05:48
|
On 11/3/2021 6:49 AM, Mainz, Roland wrote: > Hi! > > ---- > > Is there a way (sysfs, procfs, etc.) to get the list of ethX (eth0, eth1, ...) devices from a fd for a /dev/ptpXYZ device (e.g. in: fd to /dev/ptp8, out: string "eth6") ? > > ---- > > Mfg, > Roland Mainz > As far as I know, the only link between netdev and PTP device is the ethtool ioctl for timestamping. You could check every single ethernet device and see what its clock index reports in "ethtool -T"... I don't think there's anything specific in the sysfs files of the PTP devices to go backwards otherwise. Thanks, Jake |
|
From: Keller, J. E <jac...@in...> - 2021-11-03 19:03:54
|
On 11/3/2021 7:44 AM, ramesh t wrote: > Hello Jake, > > Please find the requested info below. > NIC driver: > driver: ice > version: 1.3.2 > firmware-version: 2.30 0x80006c8d 1.2877.0 > > Kernel version: > uname -a > Linux cyswy002r-mvnr-p004-sdlas00222a-mv-du001-55d64d7457-dmp8s 4.19.177-rt72-2.ph3-rt #1-photon SMP PREEMPT RT Fri Mar 5 02:22:24 UTC 2021 x86_64 GNU/Linux > > Please suggest. > > regards, > Ramesh This looks like you're using the out-of-tree driver we publish on source forge. You could try using a later version (I think we recently published the 1.6.7 driver which was published in September. There has been some work on PTP since the 1.3.x drivers and its quite possible things have improved. Alternatively, you could try a newer kernel which has the PTP support upstream now, since v5.14 Hope this helps, Jake |
|
From: ramesh t <ram...@ya...> - 2021-11-03 14:44:29
|
Hello Jake, Please find the requested info below. NIC driver: driver: ice version: 1.3.2 firmware-version: 2.30 0x80006c8d 1.2877.0 Kernel version: uname -a Linux cyswy002r-mvnr-p004-sdlas00222a-mv-du001-55d64d7457-dmp8s 4.19.177-rt72-2.ph3-rt #1-photon SMP PREEMPT RT Fri Mar 5 02:22:24 UTC 2021 x86_64 GNU/Linux Please suggest. regards, Ramesh On Wednesday, November 3, 2021, 01:38:01 AM GMT+5:30, Keller, Jacob E <jac...@in...> wrote: On 11/2/2021 2:55 AM, ramesh t via Linuxptp-users wrote: > hi, > > We are using Dell Supermicro 6212 with Intel E810 NIC card. And system was stable with ptp2.0 load. > We have disable ntpd, chronyd, systemd-timesyncd and systemd-timedated services. > Hi! Thanks for the report! The E810 code was recently upstreamed. Any chance you can tell which kernel version you are using? I believe this is a manifestation of a known issue that we're currently trying to track down. I am currently forwarding this to the engineer who is working on what I believe is the same issue. I will do my best to get back to you here if I hear anything else. Any further information you could provide may help us root cause this! Thanks, Jake _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Mainz, R. <Rol...@ro...> - 2021-11-03 13:49:33
|
Hi! ---- Is there a way (sysfs, procfs, etc.) to get the list of ethX (eth0, eth1, ...) devices from a fd for a /dev/ptpXYZ device (e.g. in: fd to /dev/ptp8, out: string "eth6") ? ---- Mfg, Roland Mainz -- Roland Mainz Entwicklung Steuerungssoftware ROVEMA GmbH Industriestr. 1, 35463 Fernwald, Germany |
|
From: Miroslav L. <mli...@re...> - 2021-11-03 13:23:44
|
On Wed, Nov 03, 2021 at 05:24:47AM -0700, Richard Cochran wrote: > On Wed, Nov 03, 2021 at 07:44:06AM +0000, Christian Leeb wrote: > > Yes it works. Also master failover. Basically we get an OC with multiple ports. > > Great. How about a patch to demote pr_warning to pr_debug? That might not be necessary. There was a change in the development code to suppress that message in the client-only mode. It would be good to confirm whether this configuration is still affected. -- Miroslav Lichvar |
|
From: Christian L. <chr...@hi...> - 2021-11-03 13:18:10
|
Yes it works. Also master failover. Basically we get an OC with multiple ports. -c Christian Leeb > -----Original Message----- > From: Richard Cochran <ric...@gm...> > Sent: Dienstag, 2. November 2021 12:57 > To: Christian Leeb <chr...@hi...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] FW: master state recommended in slave only > mode > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Tue, Nov 02, 2021 at 05:25:45AM +0000, Christian Leeb via Linuxptp-users > wrote: > > Hi > > > > I'm running a BC with slaveOnly. > > > > It behaves as expected: it sync to the best master and the other ports are > in state listening (without slaveOnly they would master). It's like an OC with > multiple ports. This is what I need. > > And it works correctly in the presence of multiple masters on different ports? > > > The only thing that irritates me a bit is the warnings: > > > > ptp4l[36702.594]: port 2: master state recommended in slave only mode > > ptp4l[36702.594]: port 2: defaultDS.priority1 probably misconfigured > > > > sent in port_slave_priority_warning() > > > > Should I worry? Is slaveOnly for BC kind of officially supported? > > If it works, then I wouldn't worry. I would test foreign master failover if that > is your aim. > > The BC as in 1588 does not have the idea of client only operation, hence the > warning message. I think what you really want is some kind of redundancy > setup, but the various possible solutions are still a WIP IMHO. > > Thanks, > Richard |
|
From: Richard C. <ric...@gm...> - 2021-11-03 12:24:55
|
On Wed, Nov 03, 2021 at 07:44:06AM +0000, Christian Leeb wrote: > Yes it works. Also master failover. Basically we get an OC with multiple ports. Great. How about a patch to demote pr_warning to pr_debug? Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2021-11-03 03:21:03
|
Thanks Richard. Will trigger a script to capture the output. regards, Ramesh On Tuesday, November 2, 2021, 10:02:01 PM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Tue, Nov 02, 2021 at 03:32:04PM +0000, ramesh t wrote: > hi, > > Any suggestion for the below mentioned issue? Please let me know. Looks like a HW and/or driver issue. I would start by validating the HW/driver. For example, a long term test of phc_ctl eth0 get HTH, Richard |
|
From: Mainz, R. <Rol...@ro...> - 2021-11-02 23:51:27
|
Hi! ---- Is there any recommended way to figure out the filename oft he ptp device if someone only has an UDP socket fd (to a network card which provides a PTP clock - in our case igb on an i210) ? ---- Bye, Roland -- Roland Mainz Entwicklung Steuerungssoftware ROVEMA GmbH Industriestr. 1, 35463 Fernwald, Germany |
|
From: Mainz, R. <Rol...@ro...> - 2021-11-02 22:40:19
|
Hi! ---- Is there any recommended way to figure out the filename oft he ptp device if someone only has an UDP socket fd (to a network card which provides a PTP clock - in our case igb on an i210) ? ---- Bye, Roland -- Roland Mainz Entwicklung Steuerungssoftware ROVEMA GmbH Industriestr. 1, 35463 Fernwald, Germany |
|
From: Keller, J. E <jac...@in...> - 2021-11-02 19:58:40
|
On 11/2/2021 2:55 AM, ramesh t via Linuxptp-users wrote: > hi, > > We are using Dell Supermicro 6212 with Intel E810 NIC card. And system was stable with ptp2.0 load. > We have disable ntpd, chronyd, systemd-timesyncd and systemd-timedated services. > Hi! Thanks for the report! The E810 code was recently upstreamed. Any chance you can tell which kernel version you are using? I believe this is a manifestation of a known issue that we're currently trying to track down. I am currently forwarding this to the engineer who is working on what I believe is the same issue. I will do my best to get back to you here if I hear anything else. Any further information you could provide may help us root cause this! Thanks, Jake |
|
From: Richard C. <ric...@gm...> - 2021-11-02 16:40:14
|
On Tue, Nov 02, 2021 at 03:32:04PM +0000, ramesh t wrote: > hi, > > Any suggestion for the below mentioned issue? Please let me know. Looks like a HW and/or driver issue. I would start by validating the HW/driver. For example, a long term test of phc_ctl eth0 get HTH, Richard |
|
From: Werner M. <wer...@gm...> - 2021-11-02 16:25:51
|
hi! you mean something like: git log v2.0..v3.0 output: changelog between tag v2.0 and tagv3.0 regards Werner On Tue, Nov 2, 2021 at 5:20 PM ramesh t via Linuxptp-devel < lin...@li...> wrote: > hi, > > Is there a way to find all the code commit between ptp 2.0 and ptp 3.0. > > Please suggest. > > regards, > Ramesh > > > _______________________________________________ > Linuxptp-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > |
|
From: ramesh t <ram...@ya...> - 2021-11-02 16:24:13
|
hi, Is there a way to find all the code commit between ptp 2.0 and ptp 3.0. Please suggest. regards, Ramesh |
|
From: ramesh t <ram...@ya...> - 2021-11-02 15:32:14
|
hi, Any suggestion for the below mentioned issue? Please let me know. regards, Ramesh On Tuesday, November 2, 2021, 03:27:54 PM GMT+5:30, ramesh t via Linuxptp-users <lin...@li...> wrote: hi, We are using Dell Supermicro 6212 with Intel E810 NIC card. And system was stable with ptp2.0 load. We have disable ntpd, chronyd, systemd-timesyncd and systemd-timedated services. regards, Ramesh On Tuesday, November 2, 2021, 02:37:27 PM GMT+5:30, Miroslav Lichvar <mli...@re...> wrote: On Tue, Nov 02, 2021 at 09:02:19AM +0000, ramesh t via Linuxptp-devel wrote: > hi, > > We are using ptp3.0 version in C3 mode. Both ptp4l and phc2sys (to sync system clock) are running fine. > > Ptp4l rms value is in single digits and we see a sudden jump in phc offset as captured below resulting in date change. > > Oct 26 19:15:48 phc2sys_slave: [1177711.923] CLOCK_REALTIME phc offset -97 s2 freq +3454 delay 2479 > Oct 26 19:15:49 ptp4l_slave: [1177712.827] rms 3 max 7 freq -2363 +/- 5 delay 86 +/- 1 > Oct 26 19:15:49 phc2sys_slave: [1177712.924] CLOCK_REALTIME phc offset -61 s2 freq +3461 delay 2433 > Oct 12 05:18:20 ptp4l_slave: [1177713.819] rms 3 max 8 freq -2364 +/- 5 delay 86 +/- 1 > Oct 19 08:03:31 phc2sys_slave: [1177713.924] clockcheck: clock jumped backward or running slower than expected! > Oct 19 08:03:31 phc2sys_slave: [1177713.924] CLOCK_REALTIME phc offset -645138994849912 s0 freq +3461 delay 2478 > Oct 25 18:44:33 ptp4l_slave: [1177714.811] rms 3 max 6 freq -2361 +/- 4 delay 86 +/- 1 > Sep 30 01:35:47 phc2sys_slave: [1177714.924] clockcheck: clock jumped backward or running slower than expected! > Sep 30 01:35:47 phc2sys_slave: [1177714.924] CLOCK_REALTIME phc offset -2310003858831797 s0 freq +3461 delay 2472 > Oct 12 07:16:54 ptp4l_slave: [1177715.803] rms 3 max 5 freq -2362 +/- 5 delay 87 +/- 1 > > Is there any known issues with ptp3.0 version? Please suggest. What hardware do you use? It's most likely a driver bug or something else (e.g. an NTP client) is trying to control the clock. -- Miroslav Lichvar _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2021-11-02 11:56:56
|
On Tue, Nov 02, 2021 at 05:25:45AM +0000, Christian Leeb via Linuxptp-users wrote: > Hi > > I'm running a BC with slaveOnly. > > It behaves as expected: it sync to the best master and the other ports are in state listening (without slaveOnly they would master). It's like an OC with multiple ports. This is what I need. And it works correctly in the presence of multiple masters on different ports? > The only thing that irritates me a bit is the warnings: > > ptp4l[36702.594]: port 2: master state recommended in slave only mode > ptp4l[36702.594]: port 2: defaultDS.priority1 probably misconfigured > > sent in port_slave_priority_warning() > > Should I worry? Is slaveOnly for BC kind of officially supported? If it works, then I wouldn't worry. I would test foreign master failover if that is your aim. The BC as in 1588 does not have the idea of client only operation, hence the warning message. I think what you really want is some kind of redundancy setup, but the various possible solutions are still a WIP IMHO. Thanks, Richard |
|
From: ramesh t <ram...@ya...> - 2021-11-02 09:56:01
|
hi, We are using Dell Supermicro 6212 with Intel E810 NIC card. And system was stable with ptp2.0 load. We have disable ntpd, chronyd, systemd-timesyncd and systemd-timedated services. regards, Ramesh On Tuesday, November 2, 2021, 02:37:27 PM GMT+5:30, Miroslav Lichvar <mli...@re...> wrote: On Tue, Nov 02, 2021 at 09:02:19AM +0000, ramesh t via Linuxptp-devel wrote: > hi, > > We are using ptp3.0 version in C3 mode. Both ptp4l and phc2sys (to sync system clock) are running fine. > > Ptp4l rms value is in single digits and we see a sudden jump in phc offset as captured below resulting in date change. > > Oct 26 19:15:48 phc2sys_slave: [1177711.923] CLOCK_REALTIME phc offset -97 s2 freq +3454 delay 2479 > Oct 26 19:15:49 ptp4l_slave: [1177712.827] rms 3 max 7 freq -2363 +/- 5 delay 86 +/- 1 > Oct 26 19:15:49 phc2sys_slave: [1177712.924] CLOCK_REALTIME phc offset -61 s2 freq +3461 delay 2433 > Oct 12 05:18:20 ptp4l_slave: [1177713.819] rms 3 max 8 freq -2364 +/- 5 delay 86 +/- 1 > Oct 19 08:03:31 phc2sys_slave: [1177713.924] clockcheck: clock jumped backward or running slower than expected! > Oct 19 08:03:31 phc2sys_slave: [1177713.924] CLOCK_REALTIME phc offset -645138994849912 s0 freq +3461 delay 2478 > Oct 25 18:44:33 ptp4l_slave: [1177714.811] rms 3 max 6 freq -2361 +/- 4 delay 86 +/- 1 > Sep 30 01:35:47 phc2sys_slave: [1177714.924] clockcheck: clock jumped backward or running slower than expected! > Sep 30 01:35:47 phc2sys_slave: [1177714.924] CLOCK_REALTIME phc offset -2310003858831797 s0 freq +3461 delay 2472 > Oct 12 07:16:54 ptp4l_slave: [1177715.803] rms 3 max 5 freq -2362 +/- 5 delay 87 +/- 1 > > Is there any known issues with ptp3.0 version? Please suggest. What hardware do you use? It's most likely a driver bug or something else (e.g. an NTP client) is trying to control the clock. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2021-11-02 09:07:42
|
On Tue, Nov 02, 2021 at 09:02:19AM +0000, ramesh t via Linuxptp-devel wrote: > hi, > > We are using ptp3.0 version in C3 mode. Both ptp4l and phc2sys (to sync system clock) are running fine. > > Ptp4l rms value is in single digits and we see a sudden jump in phc offset as captured below resulting in date change. > > Oct 26 19:15:48 phc2sys_slave: [1177711.923] CLOCK_REALTIME phc offset -97 s2 freq +3454 delay 2479 > Oct 26 19:15:49 ptp4l_slave: [1177712.827] rms 3 max 7 freq -2363 +/- 5 delay 86 +/- 1 > Oct 26 19:15:49 phc2sys_slave: [1177712.924] CLOCK_REALTIME phc offset -61 s2 freq +3461 delay 2433 > Oct 12 05:18:20 ptp4l_slave: [1177713.819] rms 3 max 8 freq -2364 +/- 5 delay 86 +/- 1 > Oct 19 08:03:31 phc2sys_slave: [1177713.924] clockcheck: clock jumped backward or running slower than expected! > Oct 19 08:03:31 phc2sys_slave: [1177713.924] CLOCK_REALTIME phc offset -645138994849912 s0 freq +3461 delay 2478 > Oct 25 18:44:33 ptp4l_slave: [1177714.811] rms 3 max 6 freq -2361 +/- 4 delay 86 +/- 1 > Sep 30 01:35:47 phc2sys_slave: [1177714.924] clockcheck: clock jumped backward or running slower than expected! > Sep 30 01:35:47 phc2sys_slave: [1177714.924] CLOCK_REALTIME phc offset -2310003858831797 s0 freq +3461 delay 2472 > Oct 12 07:16:54 ptp4l_slave: [1177715.803] rms 3 max 5 freq -2362 +/- 5 delay 87 +/- 1 > > Is there any known issues with ptp3.0 version? Please suggest. What hardware do you use? It's most likely a driver bug or something else (e.g. an NTP client) is trying to control the clock. -- Miroslav Lichvar |
|
From: ramesh t <ram...@ya...> - 2021-11-02 09:02:44
|
hi, We are using ptp3.0 version in C3 mode. Both ptp4l and phc2sys (to sync system clock) are running fine. Ptp4l rms value is in single digits and we see a sudden jump in phc offset as captured below resulting in date change. Oct 26 19:15:48 phc2sys_slave: [1177711.923] CLOCK_REALTIME phc offset -97 s2 freq +3454 delay 2479 Oct 26 19:15:49 ptp4l_slave: [1177712.827] rms 3 max 7 freq -2363 +/- 5 delay 86 +/- 1 Oct 26 19:15:49 phc2sys_slave: [1177712.924] CLOCK_REALTIME phc offset -61 s2 freq +3461 delay 2433 Oct 12 05:18:20 ptp4l_slave: [1177713.819] rms 3 max 8 freq -2364 +/- 5 delay 86 +/- 1 Oct 19 08:03:31 phc2sys_slave: [1177713.924] clockcheck: clock jumped backward or running slower than expected! Oct 19 08:03:31 phc2sys_slave: [1177713.924] CLOCK_REALTIME phc offset -645138994849912 s0 freq +3461 delay 2478 Oct 25 18:44:33 ptp4l_slave: [1177714.811] rms 3 max 6 freq -2361 +/- 4 delay 86 +/- 1 Sep 30 01:35:47 phc2sys_slave: [1177714.924] clockcheck: clock jumped backward or running slower than expected! Sep 30 01:35:47 phc2sys_slave: [1177714.924] CLOCK_REALTIME phc offset -2310003858831797 s0 freq +3461 delay 2472 Oct 12 07:16:54 ptp4l_slave: [1177715.803] rms 3 max 5 freq -2362 +/- 5 delay 87 +/- 1 Is there any known issues with ptp3.0 version? Please suggest. regards, Ramesh |
|
From: Christian L. <chr...@hi...> - 2021-11-02 05:26:01
|
Hi I'm running a BC with slaveOnly. It behaves as expected: it sync to the best master and the other ports are in state listening (without slaveOnly they would master). It's like an OC with multiple ports. This is what I need. The only thing that irritates me a bit is the warnings: ptp4l[36702.594]: port 2: master state recommended in slave only mode ptp4l[36702.594]: port 2: defaultDS.priority1 probably misconfigured sent in port_slave_priority_warning() Should I worry? Is slaveOnly for BC kind of officially supported? Best regards, Chris [cid:image001.png@01D7CF5D.732B1370] Christian Leeb PG,PGGA,2877, Senior Project Manager Hitachi ABB Power Grids Bruggerstrasse 66, 72 Aargau 5400 Baden, CH Phone: +41 58 585 19 59 Mobile: +41 79 341 57 57 [cid:image013.png@01D7CF5D.E6686B30]<https://www.facebook.com/hitachipg/> [cid:image014.png@01D7CF5D.E6686B30] <https://www.instagram.com/HitachiPG/> [cid:image015.png@01D7CF5D.E6686B30] <https://twitter.com/HitachiPG> [cid:image016.png@01D7CF5D.E6686B30] <https://www.youtube.com/HitachiABBPowerGrids> [cid:image017.png@01D7CF5D.E6686B30] <https://www.linkedin.com/company/hitachipg> [cid:image012.png@01D7CF5D.732B1370]<www.hitachiabb-powergrids.com> |
|
From: Neil M. <nm...@cc...> - 2021-11-01 12:13:55
|
Hello,
I'm running the ptp4l unicast service on some point-multipoint radio
devices (they don't support timestamped broadcasts). I'm finding that
after a link-down, link-up sequence the unicast service does not
recover. The fdtimer driving the service at the master doesn't seem to
get rearmed. I find that the patch below seems to fix the issue for me,
however I don't know the code well enough to be sure that its the right
fix. I'd be grateful for any thoughts on the matter.
Best regards,
Neil Murphy.
index d42c549..028b698 100644
--- a/unicast_service.c
+++ b/unicast_service.c
@@ -308,6 +308,7 @@ int unicast_service_add(struct port *p, struct
ptp_message *m,
if (ctmp->message_types & mask) {
/* Contract is unchanged. */
unicast_service_extend(ctmp, req);
+ unicast_service_rearm_timer(p);
return SERVICE_GRANTED;
}
/* This is the one to use. */
|
|
From: Ankur S. <ank...@gm...> - 2021-10-27 04:57:50
|
Thanks Greg for your inputs. Appreciate it. Regards, Ankur On Tue, Oct 26, 2021 at 6:50 AM Greg Armstrong < gre...@re...> wrote: > Hi Ankur, > > > > For ptp4l, have a look at the Slave Event Monitoring channel that was > introduced in v3.0. Per IEEE1588-2019, this allows the ability to monitor > the reception and transmission of PTP events. From that, you should be able > to see the offset/delay data. > > > > [Linuxptp-devel] [PATCH 00/10] Slave event monitoring (mail-archive.com) > <https://www.mail-archive.com/lin...@li.../msg04053.html> > > > > Regards, > > Greg > > > > *Greg Armstrong* > > Principal System Architect, Timing Products Division > > Renesas Electronics Canada Limited > > Mobile: 1-613-218-9373 > > > > *From:* Ankur Sharma <ank...@gm...> > *Sent:* October 25, 2021 9:43 PM > *To:* lin...@li... > *Subject:* [Linuxptp-users] Collect Offset/Delay Values > > > > Hi, > > > > I am currently looking into collecting/monitoring the offset/delay values > reported by ptp4l and phc2sys. We know that both tools print those details > to STDOUT and/or System logs file. However, is there a command line way to > collect that offset/delay data for an instance as and when needed? > (something similar to chronyc or ntpq -p) > > > > Any suggestions or pointers would be appreciated. > > > > Regards, > > Ankur > -- ankurandy |
|
From: Greg A. <gre...@re...> - 2021-10-26 14:24:35
|
Hi Ankur, For ptp4l, have a look at the Slave Event Monitoring channel that was introduced in v3.0. Per IEEE1588-2019, this allows the ability to monitor the reception and transmission of PTP events. From that, you should be able to see the offset/delay data. [Linuxptp-devel] [PATCH 00/10] Slave event monitoring (mail-archive.com)<https://www.mail-archive.com/lin...@li.../msg04053.html> Regards, Greg Greg Armstrong Principal System Architect, Timing Products Division Renesas Electronics Canada Limited Mobile: 1-613-218-9373 From: Ankur Sharma <ank...@gm...> Sent: October 25, 2021 9:43 PM To: lin...@li... Subject: [Linuxptp-users] Collect Offset/Delay Values Hi, I am currently looking into collecting/monitoring the offset/delay values reported by ptp4l and phc2sys. We know that both tools print those details to STDOUT and/or System logs file. However, is there a command line way to collect that offset/delay data for an instance as and when needed? (something similar to chronyc or ntpq -p) Any suggestions or pointers would be appreciated. Regards, Ankur |
|
From: Ankur S. <ank...@gm...> - 2021-10-26 01:43:03
|
Hi, I am currently looking into collecting/monitoring the offset/delay values reported by ptp4l and phc2sys. We know that both tools print those details to STDOUT and/or System logs file. However, is there a command line way to collect that offset/delay data for an instance as and when needed? (something similar to chronyc or ntpq -p) Any suggestions or pointers would be appreciated. Regards, Ankur |
27 messages has been excluded from this view by a project administrator.
