Thread: [Linuxptp-users] Trying to understand different behaviors of ptp4l
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Elder C. <eld...@ti...> - 2023-05-09 21:36:54
|
I am evaluating linuxptp for use in an embedded system. The basic architecture is as follows: +-------------+ +-------------+ +-------------+ | | | | | | | | | | | | | GRANDMASTER |<--->| Embedded PC |<-->| Custom board| | (PC) | | (Intel) | | | | | | | | | +-------------+ +-------------+ +-------------+ The Embedded system is constituted by an embedded PC (Intel based) and a custom board both running Linux and it is intended to be connected to an external PC (also Linux) Both the Embedded PC is running kernel 4.14.30 and the Custom board, kernel 4.14.0, both 32-bits. I compiled linuxptp 3.1.1 for both. As the custom board does not support hardware timestamp, I am experimenting with the software timestamp. I forced the custom board to client mode: sudo ptp4l -i eth0 -S -s -m -q step_threshold=0.00001 And the Embedded PC works as grandmaster for the Custom board: sudo ptp4l -i eth_am -S -m -q step_threshold=0.00001 I noticed that sometimes the master offset starts increasing as if the clock was no longer being updated. Unfortunately I did not save an instance of the log when this anomaly happened. I saved a sample of the log after running similar commands on two Fitlet PCs running Ubuntu Mate 20.04LTS (kernel 5.4.0, 64-bits OS), also running linuxptp 3.1.1 compiled in. I noticed what looks like an important difference between both configurations. This is the log of the custom board: custom_board:~$ sudo ptp4l -i eth0 -S -s -m -q step_threshold=0.00001 ptp4l[23715.187]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[23715.187]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[23721.896]: selected local clock 000a35.fffe.000122 as best master ptp4l[23728.111]: selected local clock 000a35.fffe.000122 as best master ptp4l[23735.085]: selected local clock 000a35.fffe.000122 as best master ptp4l[23742.999]: selected local clock 000a35.fffe.000122 as best master ptp4l[23749.230]: selected local clock 000a35.fffe.000122 as best master ptp4l[23755.780]: selected local clock 000a35.fffe.000122 as best master ptp4l[23761.675]: port 1: new foreign master aabbcc.fffe.ddee66-1 ptp4l[23762.677]: selected local clock 000a35.fffe.000122 as best master ptp4l[23765.675]: selected best master clock aabbcc.fffe.ddee66 ptp4l[23765.675]: foreign master not using PTP timescale ptp4l[23765.675]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[23767.674]: master offset -519361 s0 freq +100000000 path delay 64850 ptp4l[23768.674]: master offset -519678 s0 freq +100000000 path delay 64850 ptp4l[23769.674]: master offset -523460 s0 freq +100000000 path delay 65099 ptp4l[23770.674]: master offset -521308 s0 freq +100000000 path delay 65275 ptp4l[23771.674]: master offset -525323 s0 freq +100000000 path delay 65275 ptp4l[23772.674]: master offset -528631 s0 freq +100000000 path delay 65318 ptp4l[23773.675]: master offset -527435 s0 freq +100000000 path delay 65318 ptp4l[23774.675]: master offset -528132 s0 freq +100000000 path delay 65451 ptp4l[23775.675]: master offset -533678 s0 freq +100000000 path delay 65972 ptp4l[23776.675]: master offset -531624 s0 freq +100000000 path delay 65972 ptp4l[23777.675]: master offset -534432 s0 freq +100000000 path delay 66493 ptp4l[23778.675]: master offset -534855 s0 freq +100000000 path delay 65988 ptp4l[23779.675]: master offset -537967 s0 freq +100000000 path delay 66572 ptp4l[23780.675]: master offset -539110 s0 freq +100000000 path delay 66572 ptp4l[23781.675]: master offset -538102 s0 freq +100000000 path delay 65988 ptp4l[23782.675]: master offset -540316 s0 freq +100000000 path delay 66572 ptp4l[23783.675]: master offset -542282 s1 freq +99998711 path delay 66680 ptp4l[23784.675]: master offset 3549 s2 freq +99999069 path delay 66680 ptp4l[23784.675]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[23785.675]: master offset 2215 s2 freq +99998938 path delay 66680 ptp4l[23786.675]: master offset 1182 s2 freq +99998836 path delay 66749 ptp4l[23787.676]: master offset 3788 s2 freq +99999100 path delay 66749 ptp4l[23788.676]: master offset 2412 s2 freq +99998965 path delay 66749 ptp4l[23789.676]: master offset 1775 s2 freq +99998903 path delay 66749 ptp4l[23790.676]: master offset 4067 s2 freq +99999136 path delay 66680 ptp4l[23791.676]: master offset 824 s2 freq +99998813 path delay 66749 ptp4l[23792.676]: master offset 3687 s2 freq +99999103 path delay 66749 ptp4l[23793.676]: master offset 3373 s2 freq +99999075 path delay 66749 ptp4l[23794.676]: master offset 6239 s2 freq +99999368 path delay 66749 ptp4l[23795.676]: master offset 9323 s2 freq +99999686 path delay 66838 ptp4l[23796.676]: master offset 8212 s2 freq +99999583 path delay 66838 ptp4l[23797.676]: master offset 6440 s2 freq +99999412 path delay 67000 ptp4l[23798.676]: master offset 10252 s2 freq +99999803 path delay 67602 ptp4l[23799.676]: master offset 6070 s2 freq +99999391 path delay 67602 ptp4l[23800.676]: master offset 5183 s2 freq +99999308 path delay 67602 ptp4l[23801.676]: master offset 6810 s2 freq +99999477 path delay 67602 ptp4l[23802.676]: master offset 7300 s2 freq +99999533 path delay 68151 ptp4l[23803.676]: master offset 7303 s2 freq +99999541 path delay 68151 ptp4l[23804.676]: master offset 8433 s2 freq +99999663 path delay 68151 ptp4l[23805.677]: master offset 8715 s2 freq +99999699 path delay 68151 ptp4l[23806.677]: master offset 6014 s2 freq +99999435 path delay 68151 The important difference between the above and the test with the Fitlets is on the clock column, all values are +100000000 or close to it, all positive values, whereas on the Fitlets, the values are much lower and alternate between positive and negative values as well as the offsets. So it occurred there could be some software issue in this fairly old kernel version that may have been fixed in more recent kernels. Or maybe it is has to do with 32-bits vs 64-bits OS. Or I am simply doing something very wrong. Any help to help me to identify and fix this problem is welcome. TIA. |
|
From: Elder C. <eld...@ti...> - 2023-05-10 17:59:58
|
@Chris Caudle, kernel update is in the development queue. The design this one is derived from is not exposed to a network, so system stability (it is not broken, does not fix) was privileged over keeping it up to date. This new design's requirement is different and the kernel will have to be updated. I think I am misunderstanding a few t. So I have some questions to ask to clarify some points. First question is what does the freq figure means? ptp4l[11303.293]: master offset -578 s2 freq +64977 path delay 78053 ptp4l[11304.294]: master offset 425 s2 freq +65077 path delay 77958 ptp4l[11305.294]: master offset -4653 s2 freq +64565 path delay 77985 ptp4l[11306.294]: master offset -2948 s2 freq +64732 path delay 77985 What could explain its big values in the run I posted in my OP? > ptp4l[23785.675]: master offset 2215 s2 freq +99998938 path delay 66680 > ptp4l[23786.675]: master offset 1182 s2 freq +99998836 path delay 66749 > ptp4l[23787.676]: master offset 3788 s2 freq +99999100 path delay 66749 > ptp4l[23788.676]: master offset 2412 s2 freq +99998965 path delay 66749 Sometimes, when I start the slave and there is a big difference between its clock and the master's, the offset starts big: ~$ sudo ptp4l -i eth0 -S -s -m -q step_threshold=0.00001 ptp4l[11836.182]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[11836.182]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[11838.868]: port 1: new foreign master aabbcc.fffe.ddee66-1 ptp4l[11843.269]: selected best master clock aabbcc.fffe.ddee66 ptp4l[11843.269]: foreign master not using PTP timescale ptp4l[11843.269]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[11845.469]: master offset -3536460389269 s0 freq -100000000 path delay -29979969 ptp4l[11846.569]: master offset -3536360300857 s0 freq -100000000 path delay -29979969 ptp4l[11847.669]: master offset -3536274698933 s0 freq -100000000 path delay -15493484 ptp4l[11848.769]: master offset -3536181043684 s0 freq -100000000 path delay -9059394 ... ptp4l[11861.972]: master offset -3534976041966 s1 freq -1062624 path delay -13065167 ptp4l[11862.975]: master offset 2772202 s2 freq -782632 path delay -13065167 ptp4l[11862.975]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[11863.976]: master offset -6087691 s2 freq -1674709 path delay -3354109 ptp4l[11864.977]: master offset -5337010 s2 freq -1604978 path delay -2385342 ptp4l[11865.979]: master offset -4294068 s2 freq -1504978 path delay -1756173 ptp4l[11866.981]: master offset -3994368 s2 freq -1479002 path delay -486776 ptp4l[11867.983]: master offset -2451261 s2 freq -1327143 path delay -486776 ptp4l[11868.984]: master offset -1054808 s2 freq -1188552 path delay -486776 ptp4l[11869.986]: master offset 155097 s2 freq -1067407 path delay -444443 ptp4l[11870.987]: master offset 1291473 s2 freq -952478 path delay -444443 .... ptp4l[11900.000]: master offset 9506432 s2 freq +95385 path delay 77000 ptp4l[11901.000]: master offset 9478411 s2 freq +102062 path delay 77000 ptp4l[11902.001]: master offset 9442138 s2 freq +107877 path delay 77766 ptp4l[11903.001]: master offset 9397344 s2 freq +112795 path delay 78496 I think I am misusing the step_threshold parameter. What exactly this parameter does? Is there an ideal value or I should just leave it alone (just use the default)? Is there a way to force the slave's system clock to resynchronize with the master's if it changes? Assume when powered up, the grandmaster (diagram in my OP) is not connected, the clock of the Embedded PC is off and the Custom Board's system clock synchronizes with it. When the GM is connected, the EPC's will synchronize with the GM's and then I have my CB totally off. Will I need to restart ptp4l on the CB? |
|
From: Richard C. <ric...@gm...> - 2023-05-10 19:11:52
|
On Wed, May 10, 2023 at 02:35:01PM -0300, Elder Costa wrote: > I think I am misusing the step_threshold parameter. What exactly this > parameter does? See the man page (ptp4l.8) Thanks, Richard |
|
From: Elder C. <eld...@ti...> - 2023-05-10 20:15:39
|
Yes, I did read it. Several times. Unfortunately it is still not clear what it really means. That line was exactly the reason why I thought there would be some sort of clock resynchronization if there were a bigger than threshold difference between the local and the master's clock, in the first place. So, could you elaborate a little for mine and maybe other novice users? Or point to a more detailed reference? Em qua., 10 de mai. de 2023 às 16:11, Richard Cochran <ric...@gm...> escreveu: > > On Wed, May 10, 2023 at 02:35:01PM -0300, Elder Costa wrote: > > > I think I am misusing the step_threshold parameter. What exactly this > > parameter does? > > See the man page (ptp4l.8) > > Thanks, > Richard |
|
From: Richard C. <ric...@gm...> - 2023-05-10 22:25:15
|
On Wed, May 10, 2023 at 05:10:10PM -0300, Elder Costa wrote:
> Yes, I did read it. Several times. Unfortunately it is still not clear
> what it really means. That line was exactly the reason why I thought
> there would be some sort of clock resynchronization if there were a
> bigger than threshold difference between the local and the master's
> clock, in the first place. So, could you elaborate a little for mine
> and maybe other novice users? Or point to a more detailed reference?
step_threshold
The maximum offset the servo will correct by changing the clock
frequency (phase when using nullf servo) instead of stepping the
clock. When set to 0.0, the servo will never step the clock ex‐
cept on start. It's specified in seconds. The default is 0.0.
The ptp4l program estimates the client/server time offset by using the
PTP. Once the offset estimate is obtained, an action is taken to
correct the client's clock. There are two possible corrective
actions:
1. Set (aka step aka jump) the client clock to match the server's clock.
2. Slew the client clock (by changing the frequency to make it run
faster or slower) until it matches the server's clock.
By default, the ptp4l program uses method #2.
But if you set --step_threshold=X, the program will use method #1
whenever the estimated offset exceeds X.
HTH,
Richard
|
|
From: Elder C. <eld...@ti...> - 2023-05-11 12:11:47
|
Em qua., 10 de mai. de 2023 às 19:25, Richard Cochran <ric...@gm...> escreveu: > <snipped> > But if you set --step_threshold=X, the program will use method #1 > whenever the estimated offset exceeds X. Hello, Richard, thank you for the explanation. It confirms my initial understanding of the parameter. But I must be doing something wrong as I am not getting this clock step. I have run a test on two Fitlet SBCs, Ubuntu Mate 20.04 LTS, directly connected with each other. I changed the master's system clock with date midway in the test. Wasn't the slave supposed to update its system clock after a few steps? Versions: cve@cve-sbc-flt2:~$ uname -srvpi Linux 5.15.0-71-generic #78~20.04.1-Ubuntu SMP Wed Apr 19 11:26:48 UTC 2023 x86_64 x86_64 cve@cve-sbc-flt2:~$ ptp4l -v 3.1.1 Here is the log on the master side: cve@cve-sbc-flt1:~$ sudo ptp4l -4 -S -m -q -i enp3s0 [sudo] password for cve: ptp4l[5260.670]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[5260.671]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[5267.046]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[5267.046]: selected local clock 0001c0.fffe.1a3e8e as best master ptp4l[5267.046]: port 1: assuming the grand master role Here is the log on the slave side: cve@cve-sbc-flt2:~$ sudo ptp4l -4 -S -s -m -q step_threshold=0.001 -i enp3s0 ptp4l[5616.149]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[5616.149]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[5617.961]: port 1: new foreign master 0001c0.fffe.1a3e8e-1 ptp4l[5621.961]: selected best master clock 0001c0.fffe.1a3e8e ptp4l[5621.961]: foreign master not using PTP timescale ptp4l[5621.961]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[5623.963]: master offset 13926354 s0 freq +100000000 path delay 194691 ptp4l[5624.963]: master offset 13857950 s0 freq +100000000 path delay 208774 ptp4l[5625.963]: master offset 13940749 s0 freq +100000000 path delay 173620 ptp4l[5626.963]: master offset 13935717 s0 freq +100000000 path delay 194691 ptp4l[5627.964]: master offset 13933208 s0 freq +100000000 path delay 194691 ptp4l[5628.964]: master offset 13930547 s0 freq +100000000 path delay 206909 ptp4l[5629.964]: master offset 13803831 s0 freq +100000000 path delay 219127 ptp4l[5630.964]: master offset 13857327 s0 freq +100000000 path delay 219127 ptp4l[5631.964]: master offset 13917423 s0 freq +100000000 path delay 206909 ptp4l[5632.964]: master offset 13918655 s0 freq +100000000 path delay 214912 ptp4l[5633.964]: master offset 13917644 s0 freq +100000000 path delay 216194 ptp4l[5634.964]: master offset 13925743 s0 freq +100000000 path delay 215361 ptp4l[5635.964]: master offset 13917830 s0 freq +100000000 path delay 215361 ptp4l[5636.964]: master offset 13912677 s0 freq +100000000 path delay 215361 ptp4l[5637.965]: master offset 13921067 s0 freq +100000000 path delay 214761 ptp4l[5638.965]: master offset 13934802 s0 freq +100000000 path delay 213895 ptp4l[5639.965]: master offset 13926352 s1 freq +100000000 path delay 210569 ptp4l[5640.965]: master offset 7550 s2 freq +100000000 path delay 210569 ptp4l[5640.965]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[5641.965]: master offset 3335 s2 freq +100000000 path delay 209862 ptp4l[5642.965]: master offset 29048 s2 freq +100000000 path delay 198419 ptp4l[5643.965]: master offset -6089 s2 freq +99999385 path delay 198419 ptp4l[5644.965]: master offset 27372 s2 freq +100000000 path delay 194745 ptp4l[5645.966]: master offset 41165 s2 freq +100000000 path delay 180458 ptp4l[5646.966]: master offset 67436 s2 freq +100000000 path delay 180458 ptp4l[5647.966]: master offset 52707 s2 freq +100000000 path delay 180458 ptp4l[5648.966]: master offset 45178 s2 freq +100000000 path delay 195554 ptp4l[5649.966]: master offset 29094 s2 freq +100000000 path delay 195554 ptp4l[5650.966]: master offset -40457 s2 freq +99995908 path delay 203668 ptp4l[5651.966]: master offset 61863 s2 freq +100000000 path delay 189220 ptp4l[5652.966]: master offset -30990 s2 freq +99996823 path delay 203668 ptp4l[5653.967]: master offset 35655 s2 freq +100000000 path delay 203668 ptp4l[5654.967]: master offset 54452 s2 freq +100000000 path delay 203668 ptp4l[5655.967]: master offset -14750 s2 freq +99998433 path delay 203668 ptp4l[5656.967]: master offset 46659 s2 freq +100000000 path delay 197680 ptp4l[5657.967]: master offset -31081 s2 freq +99996768 path delay 193387 ptp4l[5658.967]: master offset 78940 s2 freq +100000000 path delay 193387 ptp4l[5659.967]: master offset 72995 s2 freq +100000000 path delay 188131 ptp4l[5660.968]: master offset 87009 s2 freq +100000000 path delay 188035 ptp4l[5661.968]: master offset 69708 s2 freq +100000000 path delay 189077 ptp4l[5662.968]: master offset 13182 s2 freq +100000000 path delay 189077 ptp4l[5663.968]: master offset 102075 s2 freq +100000000 path delay 189077 ptp4l[5664.968]: master offset 95211 s2 freq +100000000 path delay 189077 ptp4l[5665.968]: master offset 21393 s2 freq +100000000 path delay 189077 ptp4l[5666.968]: master offset 88257 s2 freq +100000000 path delay 189077 ptp4l[5667.968]: master offset 102154 s2 freq +100000000 path delay 189077 ptp4l[5668.968]: master offset 97624 s2 freq +100000000 path delay 189364 ptp4l[5669.968]: master offset 30572 s2 freq +100000000 path delay 189268 ptp4l[5670.969]: master offset 105652 s2 freq +100000000 path delay 189268 ptp4l[5671.969]: master offset 87663 s2 freq +100000000 path delay 189268 ptp4l[5672.969]: master offset -9329 s2 freq +99998934 path delay 200527 ptp4l[5673.969]: master offset 32310 s2 freq +100000000 path delay 187668 ptp4l[5674.969]: master offset -1504500840665 s2 freq -100000000 path delay 187668 ptp4l[5676.191]: master offset -1503498828645 s2 freq -100000000 path delay 187668 ptp4l[5677.414]: master offset -1503276540145 s2 freq -100000000 path delay 172311 ptp4l[5678.636]: master offset -1503054281517 s2 freq -100000000 path delay 172311 ptp4l[5679.859]: master offset -1502831998290 s2 freq -100000000 path delay 148551 ptp4l[5681.081]: master offset -1502592391017 s2 freq -100000000 path delay -17222716 ptp4l[5682.303]: master offset -1502337842414 s2 freq -100000000 path delay -49505012 ptp4l[5683.526]: master offset -1502099177098 s2 freq -100000000 path delay -65942473 ptp4l[5684.748]: master offset -1501876912775 s2 freq -100000000 path delay -65942473 ptp4l[5685.970]: master offset -1501661138297 s2 freq -100000000 path delay -59498317 ptp4l[5687.193]: master offset -1501435506311 s2 freq -100000000 path delay -62944579 ptp4l[5688.415]: master offset -1501213173765 s2 freq -100000000 path delay -62944579 ptp4l[5689.637]: master offset -1500990924540 s2 freq -100000000 path delay -62944579 ptp4l[5690.860]: master offset -1500775085926 s2 freq -100000000 path delay -56542343 ptp4l[5692.082]: master offset -1500550454220 s2 freq -100000000 path delay -59017651 ptp4l[5693.304]: master offset -1500323595017 s2 freq -100000000 path delay -63532925 ptp4l[5694.527]: master offset -1500101323891 s2 freq -100000000 path delay -63532925 ptp4l[5695.749]: master offset -1499877252874 s2 freq -100000000 path delay -65385477 ptp4l[5696.972]: master offset -1499658928642 s2 freq -100000000 path delay -61458549 ptp4l[5698.194]: master offset -1499436676168 s2 freq -100000000 path delay -61458549 ptp4l[5699.416]: master offset -1499214443160 s2 freq -100000000 path delay -61458549 ptp4l[5700.639]: master offset -1498992192859 s2 freq -100000000 path delay -61458549 ptp4l[5701.861]: master offset -1498771148926 s2 freq -100000000 path delay -60241977 ptp4l[5703.083]: master offset -1498548935865 s2 freq -100000000 path delay -60241977 ptp4l[5704.306]: master offset -1498326670561 s2 freq -100000000 path delay -60241977 ptp4l[5705.528]: master offset -1498103941548 s2 freq -100000000 path delay -60729906 ptp4l[5706.750]: master offset -1497881691115 s2 freq -100000000 path delay -60729906 ptp4l[5707.972]: master offset -1497660321226 s2 freq -100000000 path delay -59919762 ptp4l[5709.195]: master offset -1497434446001 s2 freq -100000000 path delay -63476816 ptp4l[5710.417]: master offset -1497207655400 s2 freq -100000000 path delay -68049885 ptp4l[5711.640]: master offset -1496985382189 s2 freq -100000000 path delay -68049885 ptp4l[5712.862]: master offset -1496744819952 s2 freq -100000000 path delay -86396769 ptp4l[5714.084]: master offset -1496527418428 s2 freq -100000000 path delay -81507676 ptp4l[5715.307]: master offset -1496314631014 s2 freq -100000000 path delay -72051250 ptp4l[5716.529]: master offset -1496092356776 s2 freq -100000000 path delay -72051250 ptp4l[5717.752]: master offset -1495866685965 s2 freq -100000000 path delay -75475651 ptp4l[5718.974]: master offset -1495659636081 s2 freq -100000000 path delay -60369227 ptp4l[5720.196]: master offset -1495422196903 s2 freq -100000000 path delay -75475651 ptp4l[5721.419]: master offset -1495212294793 s2 freq -100000000 path delay -63151399 ptp4l[5722.641]: master offset -1494995684534 s2 freq -100000000 path delay -57501401 ptp4l[5723.863]: master offset -1494773429201 s2 freq -100000000 path delay -57501401 ptp4l[5725.086]: master offset -1494536830363 s2 freq -100000000 path delay -71843099 ptp4l[5726.308]: master offset -1494314686157 s2 freq -100000000 path delay -71843099 ^Ccve@cve-sbc-flt2:~$ |
|
From: Miroslav L. <mli...@re...> - 2023-05-11 12:26:16
|
On Thu, May 11, 2023 at 08:45:02AM -0300, Elder Costa wrote: > Hello, Richard, thank you for the explanation. It confirms my initial > understanding of the > parameter. But I must be doing something wrong as I am not getting > this clock step. > cve@cve-sbc-flt2:~$ sudo ptp4l -4 -S -s -m -q step_threshold=0.001 -i enp3s0 step_threshold is an option. If specified on command line, it needs to have the "--" prefix: --step_threshold=0.001 -- Miroslav Lichvar |
|
From: Elder C. <eld...@ti...> - 2023-05-11 13:48:55
|
Hello, Miroslav, thank you very much. It worked. I stopped using the "--" because some options generated an error. For example: cve@cve-sbc-flt2:~/work/linuxptp-3.1.1$ sudo ptp4l -4 -S -m -q --clientOnly=1 --step_threshold=0.001 -i enp3s0 ptp4l: unrecognized option '--clientOnly=1' As ptp4l did not complain about the lack of --, I assumed (wrongly) it was all OK. I just learned it has been corrected in the latest version cloned from git so I will use it for further tests. Once again, thank you very much. Em qui., 11 de mai. de 2023 às 09:26, Miroslav Lichvar <mli...@re...> escreveu: > > On Thu, May 11, 2023 at 08:45:02AM -0300, Elder Costa wrote: > > Hello, Richard, thank you for the explanation. It confirms my initial > > understanding of the > > parameter. But I must be doing something wrong as I am not getting > > this clock step. > > > cve@cve-sbc-flt2:~$ sudo ptp4l -4 -S -s -m -q step_threshold=0.001 -i enp3s0 > > step_threshold is an option. If specified on command line, it needs to > have the "--" prefix: --step_threshold=0.001 > > -- > Miroslav Lichvar > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X