Am 2018-07-17 17:32, schrieb Richard Cochran:
On Tue, Jul 17, 2018 at 11:26:14AM +0200, Michael Walle wrote:
ping?
Sorry, I couldn't understand what you are trying to say.
Should I propose a fix? Ie. there have to be two versions ot t1 and
t2. One
for the offset and one for the delay calculation.
There already are two. One tsproc instance is in the clock, and the
other is in the port.
Oh I totally, missed that. But still, there is a bug somewhere. I'll
have a closer look tomorrow. If you want to try it yourself, have a look
at delay at tspoc.c:212.
Working p2p tc config:
[global]
priority1 254
free_running 1
freq_est_interval 1
follow_up_info 1
tc_spanning_tree 1
summary_interval 1
transportSpecific 0x1
assume_two_step 1
ptp_dst_mac 01:80:C2:00:00:0E
clock_type P2P_TC
network_transport L2
delay_mechanism P2P
This gets me reasonable values for delay:
[..]
tsproc.c:212 delay=282
tsproc.c:212 delay=282
[..]
Non-working config:
[global]
priority1 254
free_running 1
freq_est_interval 1
follow_up_info 1
tc_spanning_tree 1
summary_interval 1
transportSpecific 0x1
assume_two_step 1
ptp_dst_mac 01:80:C2:00:00:0E
clock_type P2P_TC
network_transport L2
delay_mechanism P2P
tsproc_mode raw
[..]
tsproc.c:212 delay=-14162673267
tsproc.c:212 delay=-14162674188
[..]
Mhh. seems like the peer delay timestampes are propagated through
clock_peer_delay() to the clock tsproc instance. And while
tsproc_set_delay() sets the correct filtered_delay, the get_raw_delay()
seems to be messed up (tsproc_down_ts() called from clock_synchronize()
for each SYNC/FOLLOW up message, while tsproc_up_ts() is called from
clock_peer_delay() for each PDELAY message).
-m
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
