linuxptp-users Mailing List for linuxptp (Page 3)
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: Nils F. <nil...@sr...> - 2023-10-19 12:40:42
|
Hello everyone! I am trying to use a NIC as a PTP GM with any external sync sorce. I have a PC with a dual port NIC (82599ES 10-Gigabit SFI/SFP+) connected to an embedded device over Ethernet. I use a SFP-to-Ethernet adapter to translate from SFP+ to Ethernet. Both devices need to be synced but I cannot use GPS or other external clock sources. My idea is to use the NIC as a PTP GM and serve the embedded device with PTP. What I am not sure about is if I need to use phc2sys to sync NIC and the physical clock of the machine hosting the NIC? What quality of sync can I expect? With my current configuration I have some PTP coming in but the quality is really bad. On the embedded device I see the following: ptp4l[2023/10/19/12:28:03]: state=2 rms 901387699 max 1000000058 freq +1353 +/- 78 delay 20569 +/- 16 ptp4l[2023/10/19/12:28:04]: state=2 rms 1245 max 4879 freq +1213 +/- 4 delay 20539 +/- 32 ptp4l[2023/10/19/12:28:05]: state=2 rms 132 max 242 freq +1196 +/- 7 delay 20442 +/- 35 ptp4l[2023/10/19/12:28:06]: state=2 rms 1031 max 4050 freq +1158 +/- 53 delay 20427 +/- 20 ptp4l[2023/10/19/12:28:07]: state=2 rms 172 max 381 freq +1065 +/- 0 delay 20401 +/- 11 ptp4l[2023/10/19/12:28:08]: state=2 rms 69 max 153 freq +1020 +/- 13 delay 20400 +/- 16 ptp4l[2023/10/19/12:28:09]: state=2 rms 105 max 300 freq +1021 +/- 4 delay 20392 +/- 10 ptp4l[2023/10/19/12:28:10]: state=2 rms 222 max 518 freq +1020 +/- 0 delay 20436 +/- 13 ptp4l[2023/10/19/12:28:11]: state=2 rms 968245340 max 999999669 freq +992 +/- 0 delay 20507 +/- 36 ptp4l[2023/10/19/12:28:13]: state=2 rms 433012546 max 999999740 freq +921 +/- 28 delay 20559 +/- 31 ptp4l[2023/10/19/12:28:14]: state=2 rms 139 max 279 freq +919 +/- 2 delay 20586 +/- 34 ptp4l[2023/10/19/12:28:15]: state=2 rms 153 max 263 freq +922 +/- 4 delay 20671 +/- 22 ptp4l[2023/10/19/12:28:16]: state=2 rms 433012402 max 999999485 freq +976 +/- 87 delay 20681 +/- 3 ptp4l[2023/10/19/12:28:18]: state=2 rms 968245358 max 999999677 freq +1084 +/- 110 delay 20724 +/- 18 ptp4l[2023/10/19/12:28:19]: state=2 rms 313 max 566 freq +803 +/- 3 delay 20727 +/- 16 Is this because I don't have an external clock source or is it about how I have configured the PTP GM? I have uploaded both configs to pastebin, you'll find the pastes here: PTP GM: https://pastebin.com/9cRBEZZn PTP Clien emb. device: https://pastebin.com/RtECRXCe I cannot adjust the config on the embedded device but I can adjust the config on the PTP GM. But unfortunately, I am not sure what I am doing wrong. I would really appreciate any help! Thanks in advance! Best regards Nils |
|
From: Jithin T R. <jit...@ta...> - 2023-10-04 05:53:04
|
Hi Team, As I am trying to getting started with ptp, as a first step, I was checking if there is any helping hand for setting up gptp client on linux machine and if there is any hands own project kind of thing (c/c++) through which we can familiarize the apis and working flow of gptp. Basically how to use gptp within a PL like c/c++. Thanks..! Bye Jithin ________________________________ Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version. ________________________________ |
|
From: Nils F. <nil...@sr...> - 2023-10-03 13:41:30
|
Ah yeah, I didnt read well. That really improved the sync quality - thanks a lot for your advice! On 3/10/23 14:38, Miroslav Lichvar wrote: > On Tue, Oct 03, 2023 at 02:33:32PM +0200, Nils Fuerste wrote: >> Thanks for your help! Unfortunately, setting those values doesn't work for >> me. I get the following errors: >> >> sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m >> -1.0 is an out of range value for option pi_proportional_const at line 73 >> failed to parse configuration file ./default-new-master.cfg > It should be pi_proportional_exponent, not pi_proportional_const. > >> $ sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m >> P is a malformed value for option pi_proportional_scale at line 75 >> failed to parse configuration file ./default-new-master.cfg > P and I should be replaced with the values from the table. > |
|
From: Nils F. <nil...@sr...> - 2023-10-03 12:39:26
|
Thanks for your help! Unfortunately, setting those values doesn't work for me. I get the following errors: sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m -1.0 is an out of range value for option pi_proportional_const at line 73 failed to parse configuration file ./default-new-master.cfg or $ sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m P is a malformed value for option pi_proportional_scale at line 75 failed to parse configuration file ./default-new-master.cfg I am on tag v4.1. Any ideas why this is not working? On 3/10/23 12:28, Miroslav Lichvar wrote: > On Tue, Oct 03, 2023 at 11:45:49AM +0200, Nils Fuerste wrote: >> I have a 82599ES from Intel [1]. I found the paramters you were referring to >> but I am not sure how to adjust them. Can you give me some guidance for this >> if you get a chance? > Try this: > pi_proportional_exponent -1 > pi_integral_exponent -1 > pi_proportional_scale P > pi_integral_scale I > > where P and I are from one line of this table: > > 0.316 0.01562 > 0.158 0.00391 > 0.079 0.00098 > 0.040 0.00024 > 0.020 0.00006 > > This is the NTPv4 (RFC 5905) PLL at five different gains. If the sync > interval is -4 (16 sync messages per second), try the middle pair > first. > |
|
From: Miroslav L. <mli...@re...> - 2023-10-03 12:38:26
|
On Tue, Oct 03, 2023 at 02:33:32PM +0200, Nils Fuerste wrote: > Thanks for your help! Unfortunately, setting those values doesn't work for > me. I get the following errors: > > sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m > -1.0 is an out of range value for option pi_proportional_const at line 73 > failed to parse configuration file ./default-new-master.cfg It should be pi_proportional_exponent, not pi_proportional_const. > $ sudo ptp4l -2 -i enp1s0f1 -f ./default-new-master.cfg -m > P is a malformed value for option pi_proportional_scale at line 75 > failed to parse configuration file ./default-new-master.cfg P and I should be replaced with the values from the table. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2023-10-03 10:28:37
|
On Tue, Oct 03, 2023 at 11:45:49AM +0200, Nils Fuerste wrote: > I have a 82599ES from Intel [1]. I found the paramters you were referring to > but I am not sure how to adjust them. Can you give me some guidance for this > if you get a chance? Try this: pi_proportional_exponent -1 pi_integral_exponent -1 pi_proportional_scale P pi_integral_scale I where P and I are from one line of this table: 0.316 0.01562 0.158 0.00391 0.079 0.00098 0.040 0.00024 0.020 0.00006 This is the NTPv4 (RFC 5905) PLL at five different gains. If the sync interval is -4 (16 sync messages per second), try the middle pair first. -- Miroslav Lichvar |
|
From: Nils F. <nil...@sr...> - 2023-10-03 09:53:33
|
Thanks for the quick answer! I have a 82599ES from Intel [1]. I found the paramters you were referring to but I am not sure how to adjust them. Can you give me some guidance for this if you get a chance? These are my current settings, basically the default.cfg: pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 Thanks for the help! Best regards Nils [1] https://www.intel.la/content/www/xl/es/products/sku/41282/intel-82599es-10-gigabit-ethernet-controller/specifications.html On 2/10/23 11:12, Miroslav Lichvar wrote: > On Mon, Oct 02, 2023 at 09:44:19AM +0200, Nils Fuerste wrote: >> Unfortunately, the sync on the server receiving the sync from the BC looks >> like this: >> >> ptp4l[3297.441]: master offset 42 s2 freq +9338 path delay >> 319 >> ptp4l[3298.441]: master offset -10 s2 freq +9298 path delay >> 319 >> ptp4l[3299.441]: master offset 19 s2 freq +9324 path delay >> 319 > That doesn't look too bad. > >> Is there a way to improve the configuration? I found the boundary_clock_jbod >> parameter but setting it to 1 didn't improve the sync. > jbod is only needed when the ports don't share the same clock. It > degrades the sync quality. > >> Can someone provide a >> configuration for a simple BC setup with one two-port NIC? What is the sync >> quality I can expect? Any help is appreciated! Thanks in advance! > It depends on the hardware. What NIC do you have? > > One thing you can try is to shorten the sync interval and decrease the > PI constants, also on the client's port of the server to minimize the > frequency noise transferred to the client. > |
|
From: Miroslav L. <mli...@re...> - 2023-10-02 09:12:56
|
On Mon, Oct 02, 2023 at 09:44:19AM +0200, Nils Fuerste wrote: > Unfortunately, the sync on the server receiving the sync from the BC looks > like this: > > ptp4l[3297.441]: master offset 42 s2 freq +9338 path delay > 319 > ptp4l[3298.441]: master offset -10 s2 freq +9298 path delay > 319 > ptp4l[3299.441]: master offset 19 s2 freq +9324 path delay > 319 That doesn't look too bad. > Is there a way to improve the configuration? I found the boundary_clock_jbod > parameter but setting it to 1 didn't improve the sync. jbod is only needed when the ports don't share the same clock. It degrades the sync quality. > Can someone provide a > configuration for a simple BC setup with one two-port NIC? What is the sync > quality I can expect? Any help is appreciated! Thanks in advance! It depends on the hardware. What NIC do you have? One thing you can try is to shorten the sync interval and decrease the PI constants, also on the client's port of the server to minimize the frequency noise transferred to the client. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2023-10-02 09:08:14
|
On Tue, Sep 26, 2023 at 05:09:52PM +0000, David Turrie via Linuxptp-users wrote: > Requests: I am seeking confirmation that linuxPTP does not allow the user to specify the slave's source IP for unicast communications. And second, if this is something the PTP development community would consider adding to PTP configuration. There is currently no option to bind the client to a specific address. It shouldn't be too difficult to add. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2023-10-02 09:06:12
|
On Wed, Sep 27, 2023 at 04:10:53PM +0100, Fernando Gomes wrote: > Hi Wolfgang, thanks! 10ns is excellent! I saw many references to DP83640 > for PTP but we need to support Gb ethernet, I've found some Vitesse PHYs > (VSC8572, VSC8574, VSC8582, VSC8584) that should also work for 1Gb > ethernet, but I'm trying to find other alternatives, mainly because these > PHYs have a limited temperature range (but similar to DP83640, 0 to 100C or > -40 to 85C) and are a bit expensive. If you know any similar solutions for > Gb ethernet please let me know. If MAC timestamping is sufficient, I think the Intel I210/211 would be a good choice. It's well supported, timestamping is stable to few tens of nanoseconds and asymmetries are already compensated in the driver. It has PPS input/output, so you can verify the accuracy. -- Miroslav Lichvar |
|
From: Nils F. <nil...@sr...> - 2023-10-02 08:46:03
|
Hello everyone! I am looking for help configuring a 2 port NIC as boundary clock. The PTP sync is coming in on one port and I want to forward it to the other one. I got something working but the sync is not as good as I expected. The sync on the receiving port looks like this: ptp4l[775]: [325626.344]: rms 7 max 13 freq -33893 +/- 11 delay 170 +/- 1 ptp4l[775]: [325626.344]: rms 7 max 13 freq -33893 +/- 11 delay 170 +/- 1 ptp4l[775]: [325627.469]: rms 5 max 11 freq -33891 +/- 9 delay 170 +/- 1 ptp4l[775]: [325627.469]: rms 5 max 11 freq -33891 +/- 9 delay 170 +/- 1 ptp4l[775]: [325628.594]: rms 4 max 9 freq -33893 +/- 6 delay 169 +/- 1 ptp4l[775]: [325628.594]: rms 4 max 9 freq -33893 +/- 6 delay 169 +/- 1 ptp4l[775]: [325629.718]: rms 9 max 14 freq -33884 +/- 14 delay 170 +/- 1 ptp4l[775]: [325629.718]: rms 9 max 14 freq -33884 +/- 14 delay 170 +/- 1 ptp4l[775]: [325630.843]: rms 3 max 5 freq -33886 +/- 5 delay 170 +/- 1 ptp4l[775]: [325630.843]: rms 3 max 5 freq -33886 +/- 5 delay 170 +/- 1 Unfortunately, the sync on the server receiving the sync from the BC looks like this: ptp4l[3297.441]: master offset 42 s2 freq +9338 path delay 319 ptp4l[3298.441]: master offset -10 s2 freq +9298 path delay 319 ptp4l[3299.441]: master offset 19 s2 freq +9324 path delay 319 ptp4l[3300.441]: master offset -23 s2 freq +9288 path delay 321 ptp4l[3301.441]: master offset 11 s2 freq +9315 path delay 321 ptp4l[3302.441]: master offset -22 s2 freq +9285 path delay 322 ptp4l[3303.441]: master offset 6 s2 freq +9307 path delay 322 Is there a way to improve the configuration? I found the boundary_clock_jbod parameter but setting it to 1 didn't improve the sync. Can someone provide a configuration for a simple BC setup with one two-port NIC? What is the sync quality I can expect? Any help is appreciated! Thanks in advance! Best regards Nils |
|
From: Nemo C. <nem...@gm...> - 2023-09-27 21:18:13
|
There is a weirdly behaving switch in the network (This switch is time unaware as well) that forwards the peer delay request & pdelay delay response that is not intended for the time follower that I am trying to time synchronize.
I could stop pdelay request being sent from this time follower by using inhibit_delay_req and initial_delay option. But still, the ptp4l is not syncing as it receives pdelay messages through this switch. Is there a way to ignore any pdelay messages being received?
Thanks,
Nemo
On Monday, 25 September, 2023 at 11:20:22 am GMT-4, Miroslav Lichvar <mli...@re...> wrote:
On Mon, Sep 25, 2023 at 03:15:23PM +0000, Nemo Crypto wrote:
> Hi Linuxptp-users,
>
> Is there a way to disable the delay mechanism? I see only 3 options in man page (E2E (default), P2P & Auto).
There is the inhibit_delay_req option. It can be combined with the
initial_delay option to set the expected delay of the sync message.
--
Miroslav Lichvar
|
|
From: Wolfgang H. <wh...@xi...> - 2023-09-27 15:41:40
|
Just as a data point, I used the DP83640 PHY in the past and got about 10ns, measured as the uncertainty in time-of-flight style physics experiments. The PHY only supports 10/100M Ethernet, but is working with LinuxPTP and can output synchronized clocks and triggers. Best regards, Wolfgang On 9/27/2023 3:34 AM, Fernando Gomes wrote: > Hi Richard, > > Thank you very much for your reply! We currently have a PTP > implementation done on an FPGA but we are looking for an alternative > without using an FPGA on simpler products. With the current > implementation, we usually have an accuracy better than 100ns (most of > the time at around 60ns), this is why I was considering the PHY > tagging, to try to have the best possible accuracy when using a CPU to > implement PTP, but I don't know what accuracy is possible when the > timestamping is done at the MAC level and at the PHY level, do you > know if there is any benchmark about that? I saw some numbers on a > discussion saying that they had an accuracy of about 200ns with MAC > level timestamping, but having more consistent data will be great, > 200ns might not be acceptable for our application, we are going to do > a proof-of-concept to validate the results, but if we know beforehand > the achievable accuracy it could avoid to do extra effort if the > required accuracy is not achievable. > > Regarding the CPU we are currently evaluating, the ethtool -T results > are different on the two ethernet ports, which should be according to > their spec since they say they only support TSN in eth0: > > ethtool -T eth0 > Time stamping parameters for eth0: > Capabilities: > hardware-transmit > software-transmit > hardware-receive > software-receive > software-system-clock > hardware-raw-clock > PTP Hardware Clock: 1 > Hardware Transmit Timestamp Modes: > off > on > Hardware Receive Filter Modes: > none > all > ptpv1-l4-event > ptpv1-l4-sync > ptpv1-l4-delay-req > ptpv2-l4-event > ptpv2-l4-sync > ptpv2-l4-delay-req > ptpv2-event > ptpv2-sync > ptpv2-delay-req > > > ethtool -T eth1 > Time stamping parameters for eth1: > Capabilities: > hardware-transmit > software-transmit > hardware-receive > software-receive > software-system-clock > hardware-raw-clock > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off > on > Hardware Receive Filter Modes: > none > all > > From the ethtool -T results, the eth1 MAC doesn't have PTP-specific > Hardware Receive Filter Modes, but it still is capable of > doing hardware timestamping at the MAC level, right? > > Is it possible to use linuxptp to implement a one-step transparent > clock? For example, when using both eth0 and eth1 ports to implement > HSR we need the PTP messages passing by the device to be correctly > adjusted to have a precise time synchronization of all devices in the > network (HSR ring). > > Best regards > > Fernando > > > > On Wed, Sep 27, 2023 at 3:47 AM Richard Cochran > <ric...@gm... <mailto:ric...@gm...>> wrote: > > On Mon, Sep 25, 2023 at 02:36:35PM +0100, Fernando Gomes wrote: > > > Is there a list of hardware that can be used with linuxptp to do > > timestamping at the hardware level (on PHY or on MAC)? There are > some phys > > that support it, like the Vitesse / Microchip, etc., but is there a > > compatibility list available? > > I used to maintain a list of hardware, but I gave that up years ago > when the number of products became too large. Nowadays most new MACs > have PTP support. > > The easiest way to find out your MAC's capabilities is: > > ethtool -T eth0 > > For PHYs, the main issue is that the Linux networking stack doesn't > treat MACs and PHYs equally. If you really need to use a PTP PHY, > then you will likely have to configure and even patch your kernel > specifically for your hardware. > > HTH, > Richard > > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users -- Wolfgang Hennig, Ph.D. XIA LLC 2744 East 11th St, Oakland, CA 94601 |
|
From: Fernando G. <f.m...@gm...> - 2023-09-27 15:11:13
|
Hi Wolfgang, thanks! 10ns is excellent! I saw many references to DP83640 for PTP but we need to support Gb ethernet, I've found some Vitesse PHYs (VSC8572, VSC8574, VSC8582, VSC8584) that should also work for 1Gb ethernet, but I'm trying to find other alternatives, mainly because these PHYs have a limited temperature range (but similar to DP83640, 0 to 100C or -40 to 85C) and are a bit expensive. If you know any similar solutions for Gb ethernet please let me know. Best regards Fernando On Wed, Sep 27, 2023 at 2:52 PM Wolfgang Hennig <wh...@xi...> wrote: > Just as a data point, I used the DP83640 PHY in the past and got about > 10ns, measured as the uncertainty in time-of-flight style physics > experiments. The PHY only supports 10/100M Ethernet, but is working with > LinuxPTP and can output synchronized clocks and triggers. > > Best regards, > > Wolfgang > > > On 9/27/2023 3:34 AM, Fernando Gomes wrote: > > Hi Richard, > > Thank you very much for your reply! We currently have a PTP implementation > done on an FPGA but we are looking for an alternative without using an FPGA > on simpler products. With the current implementation, we usually have an > accuracy better than 100ns (most of the time at around 60ns), this is why I > was considering the PHY tagging, to try to have the best possible accuracy > when using a CPU to implement PTP, but I don't know what accuracy is > possible when the timestamping is done at the MAC level and at the PHY > level, do you know if there is any benchmark about that? I saw some numbers > on a discussion saying that they had an accuracy of about 200ns with MAC > level timestamping, but having more consistent data will be great, 200ns > might not be acceptable for our application, we are going to do a > proof-of-concept to validate the results, but if we know beforehand the > achievable accuracy it could avoid to do extra effort if the required > accuracy is not achievable. > > Regarding the CPU we are currently evaluating, the ethtool -T results are > different on the two ethernet ports, which should be according to their > spec since they say they only support TSN in eth0: > > ethtool -T eth0 > Time stamping parameters for eth0: > Capabilities: > hardware-transmit > software-transmit > hardware-receive > software-receive > software-system-clock > hardware-raw-clock > PTP Hardware Clock: 1 > Hardware Transmit Timestamp Modes: > off > on > Hardware Receive Filter Modes: > none > all > ptpv1-l4-event > ptpv1-l4-sync > ptpv1-l4-delay-req > ptpv2-l4-event > ptpv2-l4-sync > ptpv2-l4-delay-req > ptpv2-event > ptpv2-sync > ptpv2-delay-req > > > ethtool -T eth1 > Time stamping parameters for eth1: > Capabilities: > hardware-transmit > software-transmit > hardware-receive > software-receive > software-system-clock > hardware-raw-clock > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off > on > Hardware Receive Filter Modes: > none > all > > From the ethtool -T results, the eth1 MAC doesn't have PTP-specific > Hardware Receive Filter Modes, but it still is capable of doing hardware > timestamping at the MAC level, right? > > Is it possible to use linuxptp to implement a one-step transparent clock? > For example, when using both eth0 and eth1 ports to implement HSR we need > the PTP messages passing by the device to be correctly adjusted to have a > precise time synchronization of all devices in the network (HSR ring). > > Best regards > > Fernando > > > > On Wed, Sep 27, 2023 at 3:47 AM Richard Cochran <ric...@gm...> > wrote: > >> On Mon, Sep 25, 2023 at 02:36:35PM +0100, Fernando Gomes wrote: >> >> > Is there a list of hardware that can be used with linuxptp to do >> > timestamping at the hardware level (on PHY or on MAC)? There are some >> phys >> > that support it, like the Vitesse / Microchip, etc., but is there a >> > compatibility list available? >> >> I used to maintain a list of hardware, but I gave that up years ago >> when the number of products became too large. Nowadays most new MACs >> have PTP support. >> >> The easiest way to find out your MAC's capabilities is: >> >> ethtool -T eth0 >> >> For PHYs, the main issue is that the Linux networking stack doesn't >> treat MACs and PHYs equally. If you really need to use a PTP PHY, >> then you will likely have to configure and even patch your kernel >> specifically for your hardware. >> >> HTH, >> Richard >> > > > _______________________________________________ > Linuxptp-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > -- > Wolfgang Hennig, Ph.D. > XIA LLC > 2744 East 11th St, > Oakland, CA 94601 > > |
|
From: Fernando G. <f.m...@gm...> - 2023-09-27 10:34:29
|
Hi Richard,
Thank you very much for your reply! We currently have a PTP implementation
done on an FPGA but we are looking for an alternative without using an FPGA
on simpler products. With the current implementation, we usually have an
accuracy better than 100ns (most of the time at around 60ns), this is why I
was considering the PHY tagging, to try to have the best possible accuracy
when using a CPU to implement PTP, but I don't know what accuracy is
possible when the timestamping is done at the MAC level and at the PHY
level, do you know if there is any benchmark about that? I saw some numbers
on a discussion saying that they had an accuracy of about 200ns with MAC
level timestamping, but having more consistent data will be great, 200ns
might not be acceptable for our application, we are going to do a
proof-of-concept to validate the results, but if we know beforehand the
achievable accuracy it could avoid to do extra effort if the required
accuracy is not achievable.
Regarding the CPU we are currently evaluating, the ethtool -T results are
different on the two ethernet ports, which should be according to their
spec since they say they only support TSN in eth0:
ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
ptpv1-l4-event
ptpv1-l4-sync
ptpv1-l4-delay-req
ptpv2-l4-event
ptpv2-l4-sync
ptpv2-l4-delay-req
ptpv2-event
ptpv2-sync
ptpv2-delay-req
ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
>From the ethtool -T results, the eth1 MAC doesn't have PTP-specific
Hardware Receive Filter Modes, but it still is capable of doing hardware
timestamping at the MAC level, right?
Is it possible to use linuxptp to implement a one-step transparent clock?
For example, when using both eth0 and eth1 ports to implement HSR we need
the PTP messages passing by the device to be correctly adjusted to have a
precise time synchronization of all devices in the network (HSR ring).
Best regards
Fernando
On Wed, Sep 27, 2023 at 3:47 AM Richard Cochran <ric...@gm...>
wrote:
> On Mon, Sep 25, 2023 at 02:36:35PM +0100, Fernando Gomes wrote:
>
> > Is there a list of hardware that can be used with linuxptp to do
> > timestamping at the hardware level (on PHY or on MAC)? There are some
> phys
> > that support it, like the Vitesse / Microchip, etc., but is there a
> > compatibility list available?
>
> I used to maintain a list of hardware, but I gave that up years ago
> when the number of products became too large. Nowadays most new MACs
> have PTP support.
>
> The easiest way to find out your MAC's capabilities is:
>
> ethtool -T eth0
>
> For PHYs, the main issue is that the Linux networking stack doesn't
> treat MACs and PHYs equally. If you really need to use a PTP PHY,
> then you will likely have to configure and even patch your kernel
> specifically for your hardware.
>
> HTH,
> Richard
>
|
|
From: Richard C. <ric...@gm...> - 2023-09-27 02:47:59
|
On Mon, Sep 25, 2023 at 02:36:35PM +0100, Fernando Gomes wrote: > Is there a list of hardware that can be used with linuxptp to do > timestamping at the hardware level (on PHY or on MAC)? There are some phys > that support it, like the Vitesse / Microchip, etc., but is there a > compatibility list available? I used to maintain a list of hardware, but I gave that up years ago when the number of products became too large. Nowadays most new MACs have PTP support. The easiest way to find out your MAC's capabilities is: ethtool -T eth0 For PHYs, the main issue is that the Linux networking stack doesn't treat MACs and PHYs equally. If you really need to use a PTP PHY, then you will likely have to configure and even patch your kernel specifically for your hardware. HTH, Richard |
|
From: David T. <dt...@sy...> - 2023-09-26 17:42:17
|
Hello, Use Case: Our application is running in a N:1 redundancy configuration. Each primary server is configured with a "real" IP address and a virtual IP address. The backup is configured with a real IP address only. The real IP address is intended for communications to the server regardless of its state (active or inactive); the virtual IP address is assigned to the server when it is active only. Besides management protocols, it is desired for PTP to use the real IP address in order to reduce impact to the grandmaster when the primary server changes its state from active to inactive (Failover) or inactive to active (Recovery). When the interface is assigned an IPv4 address, PTP uses the real IP address. When IPv6, PTP uses the virtual IP address. Our customer is using IPv6 and wants the real IP to be used. We suspect that without PTP specifying, Linux (RHEL9) is choosing the source IP in an indiscriminate manner. We could not find a PTP configuration to choose the source IP when using unicast to communicate to the master. Requests: I am seeking confirmation that linuxPTP does not allow the user to specify the slave's source IP for unicast communications. And second, if this is something the PTP development community would consider adding to PTP configuration. Thanks David Turrie This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately and delete this message and any attachment from your system. Do not copy them or disclose the contents to any other person. |
|
From: Greg A. <gre...@re...> - 2023-09-25 16:02:28
|
Latest (v4) has option for NONE:
static struct config_enum delay_mech_enu[] = {
{ "Auto", DM_AUTO },
{ "E2E", DM_E2E },
{ "P2P", DM_P2P },
{ "NONE", DM_NO_MECHANISM },
{ NULL, 0 },
};
Regards,
Greg
From: Nemo Crypto <nem...@gm...>
Sent: Monday, September 25, 2023 11:15 AM
To: Linux PTP Users Linuxptp-users <lin...@li...>
Subject: [Linuxptp-users] How to disable "Delay Mechanim" of ptp4l Time follower / slave
Hi Linuxptp-users,
Is there a way to disable the delay mechanism? I see only 3 options in man page (E2E (default), P2P & Auto).
Thanks,
Nemo
|
|
From: Miroslav L. <mli...@re...> - 2023-09-25 15:20:35
|
On Mon, Sep 25, 2023 at 03:15:23PM +0000, Nemo Crypto wrote: > Hi Linuxptp-users, > > Is there a way to disable the delay mechanism? I see only 3 options in man page (E2E (default), P2P & Auto). There is the inhibit_delay_req option. It can be combined with the initial_delay option to set the expected delay of the sync message. -- Miroslav Lichvar |
|
From: Nemo C. <nem...@gm...> - 2023-09-25 15:15:34
|
Hi Linuxptp-users, Is there a way to disable the delay mechanism? I see only 3 options in man page (E2E (default), P2P & Auto). Thanks, Nemo |
|
From: Fernando G. <f.m...@gm...> - 2023-09-25 13:36:57
|
Hi all, Is there a list of hardware that can be used with linuxptp to do timestamping at the hardware level (on PHY or on MAC)? There are some phys that support it, like the Vitesse / Microchip, etc., but is there a compatibility list available? I'm identifying components that can help the usage of linuxptp on an embedded system, and to support a precise time with Linuxptp with one step transparent clock we need to be able to do hardware timestamping. Thanks in advance! Fernando |
|
From: Maciek M. <ma...@ma...> - 2023-09-23 19:32:31
|
On 23/09/2023 02:18, allan edwards wrote: > Does anyone have a unicast ptp setup guide? > > I read the docs but nothing points to the table you create for unicast > and the settings and how they should look. Did I miss this in the docs? > You can find an example in the configs folder: https://github.com/richardcochran/linuxptp/tree/master/configs Cheers, Maciek > Thanks!!! > Allan > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: allan e. <all...@la...> - 2023-09-23 00:41:11
|
Does anyone have a unicast ptp setup guide? I read the docs but nothing points to the table you create for unicast and the settings and how they should look. Did I miss this in the docs? Thanks!!! Allan |
|
From: 曾雅詩 <yas...@ny...> - 2023-09-22 08:05:26
|
Hello, I am doing my research about TSN over 5GC with linuxptp to sync master with slave in software time stamping. My goal is to sync master and slave in different domains connect with a tunnel, which is linux tun. Master <———> virtual tunnel <———> Slave However, the slave doesn’t display the offset message, which isn’t sync. Here is my scenario: ( pic link: https://imgur.com/a/csZ13yF )  There are two NICs in VM1 which is Master and Slave respectively. with command ‘ptp4l -S -m -4 -E -i enp0s8’ and ‘ptp4l -S -m -4 -E -s -i enp0s10’ Then the packet flow will be like the green line in the above picture. I have checked that vm1 got all PTP packet from Master and Slave, but somehow it doesn’t sync. (capture with wireshark in vm2) It works (displays offset msg in slave) when i use gPTP with 'ptp4l -S -i enp0s8 -c automative-master.cfg’ and 'ptp4l -S -i enp0s10 -c automative-slave.cfg’. However, I have to use the UDPv4 to sync. I think the possible is IGMPv3 packet occurs in UDPv4 case. (I have studied some works for it, but still not understand at all) Since i am a beginner in network, can anyone tell me how to configure it ? or How can i make a change? Thanks |
|
From: John K. <jk...@ou...> - 2023-09-19 04:21:16
|
Thanks for the help. I may have got this working but I'm uncertain if some of my configuration choices were correct because some of them are only available under the global context and not individual interfaces. The specific ones from my configuration were: time_stamping step_threshold gmCapable priority1 priority2 assume_two_step I'm not sure how setting some of these for the 1588v2 configuration would impact things because most were for the gPTP case. Also, should boundary_clock_jbod be configured in global, for each interface, or only specific ones (i.e. the clients)? On Wed, Aug 30, 2023 at 11:07 AM Keller, Jacob E <jac...@in...> wrote: > You can specify both interfaces using the [<ifname>] syntax. I believe > all configuration options can be supported in each per-interface domain so > you can set the configuration options you want for each interface > separately, rather than putting them in [global]? > > > > Thanks, > > Jake > > > > *From:* John Koch via Linuxptp-users <lin...@li...> > > *Sent:* Tuesday, August 29, 2023 10:30 PM > *To:* Richard Cochran <ric...@gm...> > *Cc:* lin...@li... > *Subject:* Re: [Linuxptp-users] Multiple interfaces with different PTP > implementations > > > > I have continued to experiment with this and have been unable to figure > out how to implement an 802.1AS automotive master and 1588 slave in a > single configuration file. Any additional guidance would be appreciated. > > > > On Mon, Aug 14, 2023 at 2:27 PM John Koch <jk...@ou...> wrote: > > I apologize for my ignorance but I'm not sure how to implement that all in > a single configuration file. I currently have two very generic > configuration files. The first is used on the primary interface as the 1588 > slave: > > *[global]* > > *slaveOnly 1* > > *time_stamping hardware* > > *step_threshold 1.0* > > *delay_mechanism Auto* > > *network_transport UDPv4* > > > > *[enp11s0]* > > > > The second configuration file is the default automotive-master.cfg > profile: > https://github.com/richardcochran/linuxptp/blob/master/configs/automotive-master.cfg > > > > I run the primary configuration file like this: ptp4l -f <path_to_file> > > For the other interfaces I run: *ptp4l -f /etc/automotive-master.cfg -i > <interface_name>* > > I can add --boundary_clock_jbod to my automotive-master.cfg file and add > the automotive interfaces and a boundary clock is properly formed between > them. However, I don't know how to create a configuration file of > dissimilar PTP instances on different interfaces. I will keep investigating > and experimenting while I await a reply. > > > > On Fri, Aug 11, 2023 at 9:24 PM Richard Cochran <ric...@gm...> > wrote: > > On Fri, Aug 11, 2023 at 12:32:24PM -0600, John Koch via Linuxptp-users > wrote: > > I was wondering what the best way to configure ptp4l and phc2sys in the > > following configuration would be. > > > > There is a 1588 IPv4 PTP master present on the network. My computer has > > several NICs which have PTP hardware support, one of them is plugged into > > the network with the 1588 IPv4 master. I also have multiple devices which > > are 802.1AS automotive slaves that I want to synchronize with the rest of > > the devices on the 1588 network. Currently I have connected each of the > > 802.1AS automotive slaves to an individual NIC on my computer and run an > > instance of ptp4l and phc2sys for each slave. > > > > Is there a better way of doing this? If so could someone provide some > > guidance? > > You can run: > > - one ptp4l instance as a Boundary Clock with 1588 on the slave port > and gPTP on the master ports (using a configuration file) > > - one phc2sys in "automatic" (-a) mode with --boundary_clock_jbod > > That will make the gPTP clients synchronize to the 1588 IPv4 master. > > HTH, > Richard > > |
27 messages has been excluded from this view by a project administrator.
