linuxptp-users Mailing List for linuxptp (Page 123)
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: Harold L. <hla...@pi...> - 2015-09-16 16:18:04
|
To Whom It May Concern, In a current design using PTP IEEE-1588 (linuxptp) for clock synchronization one of the systems continues to bounce back and forth from master to slave and vice versa and the other systems maintain original master and slave status determined some time ago. From my understanding the hierarchy is created and updated automatically by the best master clock (BMC) algorithm that runs on every clock ( or PTP IEEE-1588 system), so is this a case where one system determines it should be the master and then drops back to slave (is this correct operation, if not is there some attribute setting for minimizing the occurrence)? root@zx3-pm3-zynq7:~# phc2sys -a -r -r -m phc2sys[92755.856]: reconfiguring after port state change phc2sys[92755.857]: selecting eth0 for synchronization phc2sys[92755.857]: selecting CLOCK_REALTIME as the master clock phc2sys[92755.857]: sys offset -3401 s0 freq -3910000 delay 4752 phc2sys[92756.858]: sys offset -3489 s2 freq -3910000 delay 4833 phc2sys[92757.858]: sys offset -3582 s2 freq -3910000 delay 4770 phc2sys[92758.859]: sys offset -3586 s2 freq -3910000 delay 4869 phc2sys[92759.859]: sys offset -3745 s2 freq -3910000 delay 4896 phc2sys[92760.859]: sys offset -3741 s2 freq -3910000 delay 4806 phc2sys[92761.860]: sys offset -3802 s2 freq -3910000 delay 4779 phc2sys[92762.860]: sys offset -3796 s2 freq -3910000 delay 4788 phc2sys[92763.860]: sys offset -3803 s2 freq -3910000 delay 4815 phc2sys[92764.861]: sys offset -3956 s2 freq -3910000 delay 4842 phc2sys[92765.861]: sys offset -3987 s2 freq -3910000 delay 4797 phc2sys[92766.862]: sys offset -4046 s2 freq -3910000 delay 4923 phc2sys[92767.862]: sys offset -4102 s2 freq -3910000 delay 4815 phc2sys[92768.862]: sys offset -4155 s2 freq -3910000 delay 4815 phc2sys[92769.863]: sys offset -4205 s2 freq -3910000 delay 4779 phc2sys[92770.863]: sys offset -4273 s2 freq -3910000 delay 4743 phc2sys[92771.863]: sys offset -4281 s2 freq -3910000 delay 4851 phc2sys[92772.864]: sys offset -4350 s2 freq -3910000 delay 4770 phc2sys[92773.864]: sys offset -4399 s2 freq -3910000 delay 4797 phc2sys[92774.864]: port 00214a.fffe.000003-1 changed state phc2sys[92774.865]: port 00214a.fffe.000003-1 changed state phc2sys[92774.865]: reconfiguring after port state change phc2sys[92774.865]: selecting CLOCK_REALTIME for synchronization phc2sys[92774.866]: selecting eth0 as the master clock phc2sys[92774.866]: phc offset 4756 s0 freq -33 delay 1434 phc2sys[92775.866]: phc offset 4795 s2 freq +6 delay 1425 phc2sys[92776.866]: phc offset 4830 s2 freq +4836 delay 1407 phc2sys[92777.867]: phc offset 26 s2 freq +1481 delay 1413 phc2sys[92778.867]: phc offset -1462 s2 freq +1 delay 1407 phc2sys[92779.867]: phc offset -1455 s2 freq -431 delay 1401 phc2sys[92780.868]: phc offset -984 s2 freq -396 delay 1440 phc2sys[92781.868]: phc offset -552 s2 freq -260 delay 1425 phc2sys[92782.868]: phc offset -313 s2 freq -186 delay 1380 phc2sys[92783.869]: phc offset -90 s2 freq -57 delay 1401 phc2sys[92784.869]: phc offset -32 s2 freq -26 delay 1401 phc2sys[92785.869]: phc offset 35 s2 freq +31 delay 1425 phc2sys[92786.870]: port 00214a.fffe.000003-1 changed state phc2sys[92786.870]: reconfiguring after port state change phc2sys[92786.870]: selecting eth0 for synchronization phc2sys[92786.870]: selecting CLOCK_REALTIME as the master clock phc2sys[92786.871]: sys offset 287 s2 freq -3909713 delay 4833 phc2sys[92787.871]: sys offset 280 s2 freq -3909634 delay 4824 phc2sys[92788.871]: sys offset 310 s2 freq -3909520 delay 4941 phc2sys[92789.872]: sys offset 288 s2 freq -3909449 delay 4752 phc2sys[92790.872]: sys offset 326 s2 freq -3909324 delay 4770 phc2sys[92791.872]: sys offset 299 s2 freq -3909254 delay 4752 phc2sys[92792.873]: sys offset 326 s2 freq -3909137 delay 4842 Thanks, Harold |
|
From: Richard C. <ric...@gm...> - 2015-09-15 20:26:55
|
On Tue, Sep 15, 2015 at 07:40:41PM +0000, Harold Lapprich wrote: > Thanks for the quick response. Did a search on the web for 'ptp4l > man' Why search around when you could just go to the source instead? http://sourceforge.net/projects/linuxptp Click on the big green button to download the lastest offical release. The man pages are included. To read the ptp4l man page, type "man -l ptp4l.8". > Do you have a 'step_theshold' value you would recommend No, that is really up to you. > (for that matter do you have a default configuration file > recommendation)? The file, default.cfg, is included in the TGZ file. > What is the latest release of 'linuxptp' (a new version due to be released anytime soon)? See: http://sourceforge.net/projects/linuxptp Richard |
|
From: Harold L. <hla...@pi...> - 2015-09-15 19:40:51
|
Richard, Thanks for the quick response. Did a search on the web for 'ptp4l man' and came up with a number of man documents that didn't have 'step_theshold' shown so I suspect they're from older linuxptp releases. Came across a URL document that shows 'step_theshold' being 1.0 by default but suspect this is incorrect due to your earlier response (or they have a default configuration file that is being referenced) but the document is a good reference for the specification/setting of ptp4l configuration file parameters. Do you have a 'step_theshold' value you would recommend (for that matter do you have a default configuration file recommendation)? What is the latest release of 'linuxptp' (a new version due to be released anytime soon)? Thanks, Harold URL: http://nineways.co.uk/DMA-uCLinux_ptp1588_RG_1.0.pdf AMBA DMA Controller uCLinux PTP-1588 Reference Guide ~]# ptp4l -f /ptp/defult.cfg A configuration file equivalent to the -i /dev/mtip3 -m -S options shown above would look as follows: ~]# cat default.cfg [global] verbose 1 time_stamping software [/dev/mtip3] The actual default.cfg contents are as follows: [global] twoStepFlag 1 slaveOnly 0 priority1 128 priority2 128 domainNumber 0 clockClass 248 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 logAnnounceInterval 1 logSyncInterval 0 logMinDelayReqInterval 0 logMinPdelayReqInterval 0 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval 4 neighborPropDelayThresh 20000000 assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 1 tx_timestamp_timeout 1 use_syslog 0 verbose 1 summary_interval 0 kernel_leap 1 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 step_threshold 1 first_step_threshold 0.00005 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp6_scope 0x0 uds_address /etc/uds/ptp4l delay_mechanism Auto time_stamping hardware delay_filter moving_median delay_filter_length 10 productDescription ;product name; revisionData ;MorethanIP-SWITCH/MAC-V0.1; manufacturerIdentity FF:01:22 userDescription Hardware timer counter in Fabric/Hardware [FF:01:22] - MTIP/NW identifier timeSource 0xA0 [/dev/mtip3] -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: Tuesday, September 15, 2015 1:38 PM To: Harold Lapprich <hla...@pi...> Cc: lin...@li... Subject: Re: [Linuxptp-users] ptp4l/phc2sys: Linux 'date' incorrect On Tue, Sep 15, 2015 at 04:32:09PM +0000, Harold Lapprich wrote: > How does one get a system to recover quickly from this type of issue > (i.e., 20 - 30 minutes is unreasonable and powering the unit ON/OFF > isn't an option)? Use the step_threshold configuration option. From the man page: step_threshold The maximum offset the servo will correct by changing the clock frequency instead of stepping the clock. When set to 0.0, the servo will never step the clock except on start. It's specified in seconds. The default is 0.0. This option used to be called pi_offset_const. Richard |
|
From: Richard C. <ric...@gm...> - 2015-09-15 17:38:03
|
On Tue, Sep 15, 2015 at 04:32:09PM +0000, Harold Lapprich wrote:
> How does one get a system to recover quickly from this type of issue
> (i.e., 20 - 30 minutes is unreasonable and powering the unit ON/OFF
> isn't an option)?
Use the step_threshold configuration option. From the man page:
step_threshold
The maximum offset the servo will correct by changing the clock
frequency instead of stepping the clock. When set to 0.0, the
servo will never step the clock except on start. It's specified
in seconds. The default is 0.0. This option used to be called
pi_offset_const.
Richard
|
|
From: Harold L. <hla...@pi...> - 2015-09-15 16:32:24
|
To Whom It May Concern,
Have ptp4l/phc2sys running on 3 separate systems, start system 1 and then system 2 and the output looks good ( using -m attribute) but when system 3 is started a 'GRAND_MASTER' to Faulty occurs. System 3 is immediately removed but system 2 is showing a huge master offset and it starts to slowly come down but takes 20 - 30 minutes. Have stopped and restarted system 2 but it continues with a huge master offset that continues to move downward. How does one get a system to recover quickly from this type of issue (i.e., 20 - 30 minutes is unreasonable and powering the unit ON/OFF isn't an option)?
Thanks,
Harold
system 1:
ptp4l:
root@zx3-pm3-zynq7:~# ptp4l -i eth0 -m
ptp4l[134.005]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[134.006]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[134.878]: port 1: new foreign master 00214a.fffe.000007-1
ptp4l[138.752]: selected best master clock 00214a.fffe.000007
ptp4l[138.753]: assuming the grand master role
ptp4l[138.753]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER
phc2sys:
root@zx3-pm3-zynq7:~# phc2sys -a -r -r -m
hc2sys[216.598]: sys offset 46 s2 freq -1 delay 9936
phc2sys[217.599]: sys offset 69 s2 freq +36 delay 9891
phc2sys[218.599]: sys offset 9 s2 freq -3 delay 9908
phc2sys[219.600]: sys offset -72 s2 freq -82 delay 9918
phc2sys[220.600]: sys offset -41 s2 freq -72 delay 9837
system2:
ptp4l:
root@zx3-pm3-zynq7:~# ptp4l -i eth0 -m
ptp4l[10299.159]: master offset 13496 s2 freq -92511 path delay 30399
ptp4l[10300.259]: master offset 6068 s2 freq -95890 path delay 30399
ptp4l[10301.359]: master offset 2295 s2 freq -97843 path delay 30399
ptp4l[10302.459]: master offset -787 s2 freq -100236 path delay 30399
ptp4l[10303.559]: master offset 576 s2 freq -99110 path delay 29807
ptp4l[10304.659]: master offset 3480 s2 freq -96033 path delay 27695
ptp4l[10305.759]: master offset 1531 s2 freq -96938 path delay 27059
ptp4l[10306.859]: master offset 46 s2 freq -97963 path delay 27059
system 3: brought up:
ptp4l[10826.010]: selected best master clock 000a35.fffe.00da5e
ptp4l[10826.010]: port 1: SLAVE to UNCALIBRATED on RS_SLAVE
ptp4l[10828.010]: master offset 318377681381 s2 freq +32767999 path delay 9823
ptp4l[10828.010]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[10829.002]: master offset 318344852456 s2 freq +32767999 path delay 9823
ptp4l[10829.975]: master offset 318309408666 s2 freq +32767999 path delay 2590734
ptp4l[10830.935]: master offset 318276417859 s2 freq +32767999 path delay 2706681
system 3 removed:
.
.
.
ptp4l[10826.010]: selected best master clock 000a35.fffe.00da5e
ptp4l[10826.010]: port 1: SLAVE to UNCALIBRATED on RS_SLAVE
ptp4l[10828.010]: master offset 318377681381 s2 freq +32767999 path delay 9823
ptp4l[10828.010]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[10829.002]: master offset 318344852456 s2 freq +32767999 path delay 9823
ptp4l[10829.975]: master offset 318309408666 s2 freq +32767999 path delay 2590734
ptp4l[10830.935]: master offset 318276417859 s2 freq +32767999 path delay 2706681
.
. (20 - 30 minutes)
.
ptp4l[11563.398]: master offset 26 s2 freq -108134 path delay 2554197
ptp4l[11564.300]: master offset 1272234 s2 freq +1164082 path delay 1290161
ptp4l[11565.197]: master offset 844850 s2 freq +1118368 path delay 458005
ptp4l[11566.098]: master offset -373946 s2 freq +153027 path delay 458005
ptp4l[11566.998]: master offset -426947 s2 freq -12157 path delay 257305
ptp4l[11567.898]: master offset -513853 s2 freq -227148 path delay 257305
ptp4l[11568.798]: master offset -170513 s2 freq -37963 path delay 41365
ptp4l[11569.698]: master offset -231087 s2 freq -149691 path delay 41365
ptp4l[11570.598]: master offset -161630 s2 freq -149560 path delay 23074
ptp4l[11571.498]: master offset -111912 s2 freq -148331 path delay 23074
ptp4l[11572.398]: master offset -62601 s2 freq -132594 path delay 23074
ptp4l[11573.298]: master offset -31339 s2 freq -120112 path delay 25772
ptp4l[11574.198]: master offset -10658 s2 freq -108833 path delay 25949
ptp4l[11575.098]: master offset -312 s2 freq -101684 path delay 25949
ptp4l[11575.998]: master offset 2400 s2 freq -99066 path delay 25949
ptp4l[11576.898]: master offset 3233 s2 freq -97513 path delay 25949
ptp4l[11577.798]: master offset 2215 s2 freq -97561 path delay 26035
ptp4l[11578.698]: master offset 1507 s2 freq -97605 path delay 26035
ptp4l[11579.598]: master offset 1025 s2 freq -97635 path delay 26546
ptp4l[11580.498]: master offset -221 s2 freq -98573 path delay 26813
ptp4l[11581.398]: master offset 730 s2 freq -97688 path delay 26813
ptp4l[11582.298]: master offset 119 s2 freq -98080 path delay 26813
phc2sys:
root@zx3-pm3-zynq7:~# phc2sys -a -r -r -m
phc2sys[10432.994]: phc offset 474 s2 freq -99007 delay 2727
phc2sys[10433.994]: phc offset 638 s2 freq -98701 delay 2677
phc2sys[10434.995]: phc offset -302 s2 freq -99450 delay 2682
phc2sys[10435.995]: phc offset 108 s2 freq -99130 delay 2682
phc2sys[10436.996]: phc offset 325 s2 freq -98881 delay 2679
phc2sys[10437.996]: phc offset -264 s2 freq -99372 delay 2682
phc2sys[10438.997]: phc offset -483 s2 freq -99670 delay 2682
phc2sys[10439.997]: phc offset 506 s2 freq -98826 delay 2706
phc2sys[10440.998]: phc offset -796 s2 freq -99977 delay 2686
system 3 brought up:
phc2sys[11555.873]: phc offset -4 s2 freq +32768017 delay 2591
phc2sys[11556.873]: phc offset 7 s2 freq +32768027 delay 2614
phc2sys[11557.874]: phc offset -6 s2 freq +32768016 delay 2589
phc2sys[11558.874]: phc offset -8 s2 freq +32768012 delay 2605
phc2sys[11559.875]: port 00214a.fffe.000007-1 changed state
phc2sys[11559.876]: reconfiguring after port state change
phc2sys[11559.876]: master clock not ready, waiting...
phc2sys[11562.877]: port 00214a.fffe.000007-1 changed state
phc2sys[11562.878]: reconfiguring after port state change
phc2sys[11562.878]: selecting CLOCK_REALTIME for synchronization
phc2sys[11562.878]: selecting eth0 as the master clock
phc2sys[11562.878]: phc offset 293403920992 s2 freq +100000000 delay 2641
phc2sys[11563.879]: phc offset 293292168858 s2 freq +100000000 delay 2410
phc2sys[11564.879]: phc offset 293181588380 s2 freq +100000000 delay 2416
.
. (20 - 30 minutes)
.
phc2sys[10848.490]: phc offset 262 s2 freq +32767701 delay 2640
phc2sys[10849.494]: phc offset 596 s2 freq +32768114 delay 2594
phc2sys[10850.495]: phc offset 507 s2 freq +32768204 delay 2591
phc2sys[10851.496]: phc offset 300 s2 freq +32768149 delay 2704
phc2sys[10852.496]: phc offset 186 s2 freq +32768125 delay 2597
phc2sys[10853.497]: phc offset 79 s2 freq +32768074 delay 2594
phc2sys[10854.497]: phc offset 14 s2 freq +32768032 delay 2638
phc2sys[10855.498]: phc offset 18 s2 freq +32768040 delay 2591
phc2sys[10856.499]: phc offset -1 s2 freq +32768027 delay 2594
system 3:
ptpl4:
root@zx3-pm3-zynq7:~# ptp4l -i eth0 -m
ptp4l[9570.777]: selected /dev/ptp0 as PTP clock
ptp4l[9570.781]: driver changed our HWTSTAMP options
ptp4l[9570.782]: tx_type 1 not 1
ptp4l[9570.782]: rx_filter 1 not 12
ptp4l[9570.783]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[9570.784]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[9572.743]: port 1: new foreign master 000a35.fffe.01225c-1
ptp4l[9576.743]: selected best master clock 000a35.fffe.01225c
ptp4l[9576.744]: assuming the grand master role
ptp4l[9576.744]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER
ptp4l[9593.749]: timed out while polling for tx timestamp
ptp4l[9593.749]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[9593.749]: port 1: send sync failed
ptp4l[9593.749]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[9609.753]: driver changed our HWTSTAMP options
ptp4l[9609.754]: tx_type 1 not 1
ptp4l[9609.755]: rx_filter 1 not 12
ptp4l[9609.755]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[9611.049]: port 1: new foreign master 000a35.fffe.01225c-1
|
|
From: Harini K. <har...@gm...> - 2015-09-14 10:39:25
|
Hi Richard, On Mon, Sep 14, 2015 at 3:12 PM, Richard Cochran <ric...@gm...> wrote: > On Mon, Sep 14, 2015 at 02:30:19PM +0530, Harini Katakam wrote: >> We are running linuxptp on both master and slave. The master and slave are >> either PCs with Ubuntu OS or a Xilinx embedded system with linux. The transit >> time is getting added in the TC i.e. it updates the 8 byte correction field. > > Probably your custom TC is broken. I would guess that it is either > dropping the Delay_Req or mangling it beyond recognition. > > You can confirm the non-zero correction field is NOT the problem by: > > 1. setting delayAsymmetry to 1 > 2. take your buggy TC out of the loop (use 2 PCs point to point) > 3. observe how it works just fine > Yes, this works. We are enabling deeper log level and debugging. Will analyze further. Thanks for the quick reply. Regards, Harini |
|
From: Richard C. <ric...@gm...> - 2015-09-14 09:42:49
|
On Mon, Sep 14, 2015 at 02:30:19PM +0530, Harini Katakam wrote: > We are running linuxptp on both master and slave. The master and slave are > either PCs with Ubuntu OS or a Xilinx embedded system with linux. The transit > time is getting added in the TC i.e. it updates the 8 byte correction field. Probably your custom TC is broken. I would guess that it is either dropping the Delay_Req or mangling it beyond recognition. You can confirm the non-zero correction field is NOT the problem by: 1. setting delayAsymmetry to 1 2. take your buggy TC out of the loop (use 2 PCs point to point) 3. observe how it works just fine Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-09-14 09:15:51
|
On Mon, Sep 14, 2015 at 02:30:19PM +0530, Harini Katakam wrote: > We are running linuxptp on both master and slave. The master and slave are > either PCs with Ubuntu OS or a Xilinx embedded system with linux. The transit > time is getting added in the TC i.e. it updates the 8 byte correction field. > Does linuxptp consider this field in delay computations? Yes. > What config needs to be enabled for the same? No configuration needed. The correction fields are automatically included in the offset calculation. See port_synchronize() in port.c > When we tried this by updating the correction field > (even if only with 1 ns), we observed a hang - there was no DelayResponse frame > observed and the sync stopped in s2 stage. If the correction field is made > zero again (dynamically in the TC), the sync resumes as expected. I find it hard to believe that ptp4l would hang like this. Just what do you mean by "hang"? Thanks, Richard |
|
From: Harini K. <har...@gm...> - 2015-09-14 09:00:28
|
Hi, Could you please help us out on a query regarding the use of non-zero correction field in PTP event frames? We are working on a 1588 solution with a setup involving transparent clock. The setup is essentially as follows: 1588_Master <===> E2E_TC <===> 1588_Slave We are running linuxptp on both master and slave. The master and slave are either PCs with Ubuntu OS or a Xilinx embedded system with linux. The transit time is getting added in the TC i.e. it updates the 8 byte correction field. Does linuxptp consider this field in delay computations? What config needs to be enabled for the same? When we tried this by updating the correction field (even if only with 1 ns), we observed a hang - there was no DelayResponse frame observed and the sync stopped in s2 stage. If the correction field is made zero again (dynamically in the TC), the sync resumes as expected. We have looked up other queries on delay correction on the mailing list but they were mostly static delays that can be handled in the kernel driver. This is specifically regarding the correction field (offset 8 bytes from PTPHDR, size 8 bytes) . Please suggest how to proceed. Regards, Harini |
|
From: Richard C. <ric...@gm...> - 2015-09-05 20:02:42
|
Dear linuxptp users and developers, Soon it will be time, once again, for a release. We have two shiny new features, the tsproc and the hybrid mode. The tsproc code has been in git for a while, but I only just pushed out the hybrid mode today. I would like to release version 1.6 in about two weeks, so please give the new features a try. Also, if there are any issues with the current git head, now is the time to report them! Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-09-04 12:06:24
|
On Fri, Sep 04, 2015 at 01:42:01PM +0200, Xavier Bestel wrote: > The ESMC message defined here:https://en.wikipedia.org/wiki/Synchronous_Ethernet#Messaging_channel Oh, that. Yes, I did implement that in 400 LOC for a customer project. It is a very simple protocol. What we really need is an ethtool command to enable and disable SyncE. I posted an idea to the netdev list, and there was a little bit of interest. Maybe if I get some SyncE HW, I'll work on that again. Thanks, Richard |
|
From: Xavier B. <xav...@fr...> - 2015-09-04 11:42:17
|
Le 04/09/2015 13:33, Richard Cochran a écrit : > On Fri, Sep 04, 2015 at 12:35:59PM +0200, Xavier Bestel wrote: >> Generally speaking, do you know which support is needed in the host CPU (or >> SoC) for SyncE ? From what I gather whith PHYCR2:13 you have syntonized the >> ethernet endpoints, but you still don't send the heartbeat and everything do >> you ? > What do you mean by "heartbeat"? The ESMC message defined here:https://en.wikipedia.org/wiki/Synchronous_Ethernet#Messaging_channel Xav |
|
From: Richard C. <ric...@gm...> - 2015-09-04 11:33:45
|
On Fri, Sep 04, 2015 at 12:35:59PM +0200, Xavier Bestel wrote: > Generally speaking, do you know which support is needed in the host CPU (or > SoC) for SyncE ? From what I gather whith PHYCR2:13 you have syntonized the > ethernet endpoints, but you still don't send the heartbeat and everything do > you ? What do you mean by "heartbeat"? Richard |
|
From: Xavier B. <xav...@fr...> - 2015-09-04 10:36:14
|
Oh, that was a hidden feature !
Thanks Richard.
Generally speaking, do you know which support is needed in the host CPU
(or SoC) for SyncE ? From what I gather whith PHYCR2:13 you have
syntonized the ethernet endpoints, but you still don't send the
heartbeat and everything do you ?
Xav
Le 04/09/2015 11:42, Richard Cochran a écrit :
> On Fri, Sep 04, 2015 at 10:49:40AM +0200, Xavier Bestel wrote:
>> Out of curiosity how do you use SyncE on this hardware ?
>> I can't see the DP83640 doing SyncE.
> Set bit 13 in PHYCR2 (PAGE0).
>
> HTH
> Ricahrd
>
>
|
|
From: Richard C. <ric...@gm...> - 2015-09-04 09:42:29
|
On Fri, Sep 04, 2015 at 10:49:40AM +0200, Xavier Bestel wrote: > Out of curiosity how do you use SyncE on this hardware ? > I can't see the DP83640 doing SyncE. Set bit 13 in PHYCR2 (PAGE0). HTH Ricahrd |
|
From: Xavier B. <xav...@fr...> - 2015-09-04 08:49:57
|
OnThu, 19 Mar 2015 09:30:56 -0700 <https://www.mail-archive.com/search?l=lin...@li...&q=date:20150319>, Richard Cochran wrote: > Here is a random metric from the boards on my desk. The CPUs are the > TI AM335x, but using the DP83640 PHY as the PTP Hardware Clock. The > slave is directly connected to the master with 1 meter cable over a > 100 Mbit link. > > Measuring the edges of a 1 kHz output at various Sync rates, and with > a DelayReq rate of 1 Hz, I see the following differences. > > Rate Offset > ---------------- > 2^0 +/- 75 ns > 2^-3 +/- 25 ns > 2^-4 +/- 20 ns > 2^-5 +/- 20 ns > > As expected, increasing the DelayReq rate to 2^-5 makes no difference. > > So with this hardware, I have already reached the limit of > synchronization performance. Increasing the Sync rate to 512 frames > per second would not improve the picture. > > In contrast, using SyncE on the exact same hardware immediately yields > an offset of +/- 1 nanosecond. (Actually, it probably is smaller, but > I can't measure it with my lousy scope.) Hi Richard, Out of curiosity how do you use SyncE on this hardware ? I can't see the DP83640 doing SyncE. Xav |
|
From: Richard C. <ric...@gm...> - 2015-09-02 07:01:44
|
On Tue, Sep 01, 2015 at 09:34:32PM +0000, Keller, Jacob E wrote: > By die gracefully here, I mean not segfault, but just instantly quit. Right, and Miroslav's recent patches do catch a malloc failure and call exit() in that case. Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2015-09-01 21:34:41
|
> -----Original Message----- > From: Miroslav Lichvar [mailto:mli...@re...] > Sent: Thursday, August 27, 2015 8:16 AM > To: lin...@li... > Subject: Re: [Linuxptp-users] Missing Sanity Checks for > malloc()/calloc()/strdup() in linuxptp-1.5 > > On Thu, Aug 27, 2015 at 04:06:23PM +0200, Xavier Bestel wrote: > > Under linux malloc() will only return NULL when you get out of address > > space, i.e. virtually never on a 64bits machine. Low memory situations are > > handled elsewhere (e.g. OOM killer). > > So I don't think checking malloc() for NULL is that wise. > > It depends on the kernel overcommit configuration. In the default > configuration getting NULL is unlikely, but that doesn't mean it > should result in a segfault. I'm just not convinced there is any point > in trying to recover from that. > Generally, no, and I would prefer we at least try and die gracefully, and if *every* place we check will die gracefully, then why force each end point to die itself? By die gracefully here, I mean not segfault, but just instantly quit. Regards, Jake |
|
From: Richard C. <ric...@gm...> - 2015-08-31 08:22:23
|
On Sun, Aug 30, 2015 at 10:28:15PM +0100, Guo Hao wrote: > Hence the working principle would be as: > 1. The Endace card might get the ToD second (from NTP or PTP) before the > accurate 1-PPS or after the 1-PPS > 2. If the ToD second comes first then 1-PPS comes later, Endace card would > record the ToD second and match that second to the moment when it really > receives the 1-PPS. > 3. If the 1-PPS comes first and ToD second comes later, Endace card would > add some offset to the ToD second to make that align to the 1-PPS. > > Is my understanding correct or not? Yes, I think so. > Still not that clear on how the Endace card coordinate NTP ToD with PPS and > can you give more clues? You can always ask Endace how their card works... Thanks, Richard |
|
From: Guo H. <gh...@gm...> - 2015-08-30 21:28:23
|
Hi Richard, Thanks a lot for the clarification. #The ToD is really only telling your endace card the *approximate* date #and time. Your endace card phase locks (not just frequency locks) to #the PPS. Hence the working principle would be as: 1. The Endace card might get the ToD second (from NTP or PTP) before the accurate 1-PPS or after the 1-PPS 2. If the ToD second comes first then 1-PPS comes later, Endace card would record the ToD second and match that second to the moment when it really receives the 1-PPS. 3. If the 1-PPS comes first and ToD second comes later, Endace card would add some offset to the ToD second to make that align to the 1-PPS. Is my understanding correct or not? Still not that clear on how the Endace card coordinate NTP ToD with PPS and can you give more clues? > As far as I know, the GPS clock might already did something about the > egress and ingress latency. # And just how do you know that? # It cannot possibly know the ingress latency of the Endace card.) Sorry to confuse you. What I want to say is that the GPS clock would have already compensate the egress latency of the PTP messages introduced by itself as well as the ingress latency of the PTP messages introduced by itself. It is for sure that the GPS clock does not know the ingress latency of the Endace card. According to the one of the GPS clock manufacturer, their egress latency should be less than 100 ns. To sum up the installation of Linuxptp on Ubuntu: 1. Check the kernel version of Ubuntu by command "uname -a". Ubuntu 14.04 kernel version 3.16 has already supported PTP features and there is no need to compile own kernel. 2. Check whether the Network Interface Card (NIC) supports hardware timestamping by command "ethtool -T eth0 (NIC name)". Intel 82574 NIC supports hardware timestamping. 3. Download Linuxptp source code (tarball) from http://linuxptp.sourceforge.net/ 4. Untar the tarball and change to the directory; then type command "make" to compile the source code 5. Check whether the program works by command "./ptp4l -E -2 -H -i eth0 -m -q"; for help menu of ptp4l, type "./ptp4l -h" 6. Install the the source code by "make install" 7. After successful installation of Linuxptp, could run program ptp4l, pmc and phc2sys directly from terminal / command line. 8. "ptp4l -h", "pmc -h", "pmc help" and "phc2sys -h" for help of the programs ptp4l, pmc and phc2sys Best regards, Hao On 30 August 2015 at 15:01, Richard Cochran <ric...@gm...> wrote: > On Sat, Aug 29, 2015 at 08:35:56PM +0100, Guo Hao wrote: > > But what if there is certain time offset between GPS clock's ToD and host > > PC's ToD, say 3 us when the capture card gets its initial ToD from the > PC. > > Then even the capture has 1-PPS from the GPS clock, the timestamp > > difference would be in the range of 3 us? > > The ToD is really only telling your endace card the *approximate* date > and time. Your endace card phase locks (not just frequency locks) to > the PPS. > > Endace said: > > > Yes, your understanding is correct: the host clock sets the DAG’s initial > > TOD for time stamping and the PPS keeps the oscillator on the DAG from > > drifting. This way once the initial TOD is established if the DAG has > > proper sync the largest possible timing skew would be a few > > nanoseconds. > > and I said: > > > # so the ToD from the host is irrelevant. The capture has the GPS's > > # 1-PPS, and so the phase of its time stamps should be correct to a few > > # hundred nanoseconds. > > See how you got the same answer twice? > > > As far as I know, the GPS clock might already did something about the > > egress and ingress latency. > > And just how do you know that? > > (It cannot possibly know the ingress latency of the Endace card.) > > > Therefore, I guess most of the latency might be introduced by the capture > > card. > > Could be. > > Cheers, > Richard > |
|
From: Guo H. <gh...@gm...> - 2015-08-30 21:27:42
|
Hi,
I agree with Dale that ppb is dimensionless and it is a ratio.
So 1 ns is 1 ppb of a second.
Meanwhile, as far as I know, ppb and ppm are mainly used to indicate the
stability of an oscillator.
When we talk about ppb / ppm, it might be more related to the frequency.
Best regards,
Hao
On 30 August 2015 at 07:55, 林志剛 <dun...@gm...> wrote:
> so, the unit of master offset is nanosecond?how to convert to ppb?
> 2015/8/30 上午2:10於 "Richard Cochran" <ric...@gm...>寫道：
>
>> On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote:
>> > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay
>> > 825
>> >
>> > Does this mean the clock offset between the 82574 NIC and the Master
>> Clock
>> > is in the range less than 100 ns?
>>
>> Yes.
>>
>> > Does that mean the system time is synchronized to the ptp hardware
>> clock on
>> > the 82574 NIC?
>>
>> Yes, but remember that there is probably some offset in the low
>> microseconds range. The "delay" tells you that reading the PHC time
>> over the PCIe bus takes about 13 microseconds.
>>
>> > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu:
>> >
>> > root@Hao-Ubuntu:~# service ptp4l start
>> > ptp4l: unrecognized service
>> > root@Hao-Ubuntu:~#
>> >
>> > Any idea on this?
>>
>> Just start the programs by hand. To start them automatically, one
>> easy way is to put the commands into /etc/rc.local.
>>
>> > Therefore, I doubt whether there is a inherent delay between the point
>> when
>> > the Ethernet capture card request for the ToD and point the Ethernet
>> > capture card really gets the information or the system time is not
>> > synchronized by the hardware clock of the 82574 NIC.
>>
>> But you said,
>>
>> the Ethernet capture card gets the 1-PPS from the same GPS clock.
>>
>> so the ToD from the host is irrelevant. The capture has the GPS's
>> 1-PPS, and so the phase of its time stamps should be correct to a few
>> hundred nanoseconds.
>>
>> The ~1 usec difference is probably just the sum of the GPS device's
>> egress latency and the capture card's ingress latency. The number is
>> perfectly reasonable, if one or both of the devices has MAC time
>> stamping.
>>
>> HTH,
>> Richard
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Linuxptp-users mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>>
>
|
|
From: Dale S. <dal...@gm...> - 2015-08-30 17:21:47
|
ppb is dimensionless, but one nanosecond is one ppb of a second, so... -Dale On Sun, Aug 30, 2015 at 2:55 AM, 林志剛 <dun...@gm...> wrote: > so, the unit of master offset is nanosecond?how to convert to ppb? > 2015/8/30 上午2:10於 "Richard Cochran" <ric...@gm...>寫道： > >> On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote: >> > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay >> > 825 >> > >> > Does this mean the clock offset between the 82574 NIC and the Master >> Clock >> > is in the range less than 100 ns? >> >> Yes. >> >> > Does that mean the system time is synchronized to the ptp hardware >> clock on >> > the 82574 NIC? >> >> Yes, but remember that there is probably some offset in the low >> microseconds range. The "delay" tells you that reading the PHC time >> over the PCIe bus takes about 13 microseconds. >> >> > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: >> > >> > root@Hao-Ubuntu:~# service ptp4l start >> > ptp4l: unrecognized service >> > root@Hao-Ubuntu:~# >> > >> > Any idea on this? >> >> Just start the programs by hand. To start them automatically, one >> easy way is to put the commands into /etc/rc.local. >> >> > Therefore, I doubt whether there is a inherent delay between the point >> when >> > the Ethernet capture card request for the ToD and point the Ethernet >> > capture card really gets the information or the system time is not >> > synchronized by the hardware clock of the 82574 NIC. >> >> But you said, >> >> the Ethernet capture card gets the 1-PPS from the same GPS clock. >> >> so the ToD from the host is irrelevant. The capture has the GPS's >> 1-PPS, and so the phase of its time stamps should be correct to a few >> hundred nanoseconds. >> >> The ~1 usec difference is probably just the sum of the GPS device's >> egress latency and the capture card's ingress latency. The number is >> perfectly reasonable, if one or both of the devices has MAC time >> stamping. >> >> HTH, >> Richard >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Linuxptp-users mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > |
|
From: Richard C. <ric...@gm...> - 2015-08-30 14:01:14
|
On Sat, Aug 29, 2015 at 08:35:56PM +0100, Guo Hao wrote: > But what if there is certain time offset between GPS clock's ToD and host > PC's ToD, say 3 us when the capture card gets its initial ToD from the PC. > Then even the capture has 1-PPS from the GPS clock, the timestamp > difference would be in the range of 3 us? The ToD is really only telling your endace card the *approximate* date and time. Your endace card phase locks (not just frequency locks) to the PPS. Endace said: > Yes, your understanding is correct: the host clock sets the DAG’s initial > TOD for time stamping and the PPS keeps the oscillator on the DAG from > drifting. This way once the initial TOD is established if the DAG has > proper sync the largest possible timing skew would be a few > nanoseconds. and I said: > # so the ToD from the host is irrelevant. The capture has the GPS's > # 1-PPS, and so the phase of its time stamps should be correct to a few > # hundred nanoseconds. See how you got the same answer twice? > As far as I know, the GPS clock might already did something about the > egress and ingress latency. And just how do you know that? (It cannot possibly know the ingress latency of the Endace card.) > Therefore, I guess most of the latency might be introduced by the capture > card. Could be. Cheers, Richard |
|
From: 林志剛 <dun...@gm...> - 2015-08-30 06:55:48
|
so, the unit of master offset is nanosecond?how to convert to ppb? 2015/8/30 上午2:10於 "Richard Cochran" <ric...@gm...>寫道： > On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote: > > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay > > 825 > > > > Does this mean the clock offset between the 82574 NIC and the Master > Clock > > is in the range less than 100 ns? > > Yes. > > > Does that mean the system time is synchronized to the ptp hardware clock > on > > the 82574 NIC? > > Yes, but remember that there is probably some offset in the low > microseconds range. The "delay" tells you that reading the PHC time > over the PCIe bus takes about 13 microseconds. > > > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu: > > > > root@Hao-Ubuntu:~# service ptp4l start > > ptp4l: unrecognized service > > root@Hao-Ubuntu:~# > > > > Any idea on this? > > Just start the programs by hand. To start them automatically, one > easy way is to put the commands into /etc/rc.local. > > > Therefore, I doubt whether there is a inherent delay between the point > when > > the Ethernet capture card request for the ToD and point the Ethernet > > capture card really gets the information or the system time is not > > synchronized by the hardware clock of the 82574 NIC. > > But you said, > > the Ethernet capture card gets the 1-PPS from the same GPS clock. > > so the ToD from the host is irrelevant. The capture has the GPS's > 1-PPS, and so the phase of its time stamps should be correct to a few > hundred nanoseconds. > > The ~1 usec difference is probably just the sum of the GPS device's > egress latency and the capture card's ingress latency. The number is > perfectly reasonable, if one or both of the devices has MAC time > stamping. > > HTH, > Richard > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: Guo H. <gh...@gm...> - 2015-08-29 19:36:04
|
Hi Richard,
Thanks a lot the reply.
# so the ToD from the host is irrelevant. The capture has the GPS's
# 1-PPS, and so the phase of its time stamps should be correct to a few
# hundred nanoseconds.
But what if there is certain time offset between GPS clock's ToD and host
PC's ToD, say 3 us when the capture card gets its initial ToD from the PC.
Then even the capture has 1-PPS from the GPS clock, the timestamp
difference would be in the range of 3 us?
Since the 1-PPS just trains the internal oscillator of the capture and its
timestamp only ticks forward based on the 1-PPS.
I am not sure whether my understanding is correct or not.
Below is the feedback I got from the Endace support (DAG is the capture
card):
Hi Hao,
Yes, your understanding is correct: the host clock sets the DAG’s initial
TOD for time stamping and the PPS keeps the oscillator on the DAG from
drifting. This way once the initial TOD is established if the DAG has
proper sync the largest possible timing skew would be a few nanoseconds. If
for some reason the delta between the DAG and the host clock becomes too
great (1 second in older drivers, 0.5 seconds in newer drivers) the DAG
card will automatically reset the TOD to the new value and resync. Other
than that, the DAG will always maintain TOD based off of the initial start,
with the PPS as it’s tick corrector.
However, if the ToD does matter, then the result should be totally
different when using NTP and PTP.
That is a bit strange...
# The ~1 usec difference is probably just the sum of the GPS device's
# egress latency and the capture card's ingress latency. The number is
# perfectly reasonable, if one or both of the devices has MAC time
# stamping.
As far as I know, the GPS clock might already did something about the
egress and ingress latency.
Therefore, I guess most of the latency might be introduced by the capture
card.
It is also interesting that when I use the capture card under Windows 7, it
gave me the time difference in the range of 3.4 - 3.7 us.
Best regards,
Hao
On 29 August 2015 at 19:09, Richard Cochran <ric...@gm...>
wrote:
> On Sat, Aug 29, 2015 at 06:09:56PM +0100, Guo Hao wrote:
> > ptp4l[7726.711]: master offset -8 s2 freq +3835 path delay
> > 825
> >
> > Does this mean the clock offset between the 82574 NIC and the Master
> Clock
> > is in the range less than 100 ns?
>
> Yes.
>
> > Does that mean the system time is synchronized to the ptp hardware clock
> on
> > the 82574 NIC?
>
> Yes, but remember that there is probably some offset in the low
> microseconds range. The "delay" tells you that reading the PHC time
> over the PCIe bus takes about 13 microseconds.
>
> > However I cannot run ptp4l and phc2sys as a daemon process under Ubuntu:
> >
> > root@Hao-Ubuntu:~# service ptp4l start
> > ptp4l: unrecognized service
> > root@Hao-Ubuntu:~#
> >
> > Any idea on this?
>
> Just start the programs by hand. To start them automatically, one
> easy way is to put the commands into /etc/rc.local.
>
> > Therefore, I doubt whether there is a inherent delay between the point
> when
> > the Ethernet capture card request for the ToD and point the Ethernet
> > capture card really gets the information or the system time is not
> > synchronized by the hardware clock of the 82574 NIC.
>
> But you said,
>
> the Ethernet capture card gets the 1-PPS from the same GPS clock.
>
> so the ToD from the host is irrelevant. The capture has the GPS's
> 1-PPS, and so the phase of its time stamps should be correct to a few
> hundred nanoseconds.
>
> The ~1 usec difference is probably just the sum of the GPS device's
> egress latency and the capture card's ingress latency. The number is
> perfectly reasonable, if one or both of the devices has MAC time
> stamping.
>
> HTH,
> Richard
>
>
|
27 messages has been excluded from this view by a project administrator.
