How to communicate with PTP linux PC? Topic is solved

New to XMOS and XCore? Get started here.
nick
Member++
Posts: 25
Joined: Tue Jan 07, 2020 10:35 am

Re: How to communicate with PTP linux PC?

Postby nick » Thu Sep 03, 2020 2:01 pm

Ok I agree with that.
I try to better explain myself. What I'm interested in at the moment is to undestand the PTP mechanism.
PTP is used to synchronize two system clocks by estimating the offset of the slave's clock respect to the master clock. Excluding for a moment the recovery of the media clock, I think that two systems running PTP are synchronized by only the protocol itself (or not?).
What I don't understand is if XMOS implemented this in the ptp_server task tuning the system clock (not gptp_media_clock_server) or if the ptp_server gives us only a timestamp which is useless without a more complicated procedure (as you said: recovery a media clock by using timestamping of PTP and the one contained in AVB streams).
View Solution
User avatar
akp
Respected Member
Posts: 441
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Thu Sep 03, 2020 2:11 pm

I don't know if this answers your question -- since I use gPTP and I'm not sure that's what you're doing -- is that once the gPTP clock is slaved to a master clock the device computes PTP time between synchronization events by estimating the rate bias between the CPU time and PTP time and using that to estimate the actual PTP time since last synchronization event. This is what I am understanding from the code

PTP_time_now_est = (CPU_time_now - CPU_time_last_sync) * rate_bias_est + PTP_time_last_sync
nick
Member++
Posts: 25
Joined: Tue Jan 07, 2020 10:35 am

Postby nick » Thu Sep 03, 2020 2:20 pm

So PTP gives, let's call it, a software clock. Or maybe better, it says (with a timestamp) how much the slave is late or early compared to the master.
XMOS is able to synchronize with this notion of time not by using the timestamp itself, but by creating a clock signal (as you said: based on the comparison between CPU time and PTP time) which will be used as master clock of the system. Is this correct?
User avatar
akp
Respected Member
Posts: 441
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Thu Sep 03, 2020 2:38 pm

I think that's accurate. In the sense that it will be the master clock to any slaves (if you have a system with multiple ports) and it will be the time you get when you query the current ptp time. It doesn't affect the local clock in any way, though, so your local clock (i.e. what you get when you make the xc statement tmr :> t) will still be whatever the oscillator does.
nick
Member++
Posts: 25
Joined: Tue Jan 07, 2020 10:35 am

Postby nick » Thu Sep 03, 2020 2:40 pm

Ok thank you so much
fabra
Member
Posts: 13
Joined: Sat May 09, 2020 4:20 pm

Postby fabra » Wed Sep 16, 2020 7:11 pm

Another note that might be helpful:
In order to test PTP implementations it is good practice to implement a PPS (pulse per second) output. Meaning that you create a pulse when a full second is reached. As mentioned above you have to keep track of your local timer and it's relation to the "soft" ptp time. When that calculation is done correctly you can probe the PPS outputs of two endpoints and verify whether they synchronise.
nick
Member++
Posts: 25
Joined: Tue Jan 07, 2020 10:35 am

Postby nick » Thu Sep 17, 2020 10:30 am

Thank you fabra, I'll try.

Currently I'm having problems setting linux_ptp as asCapable=0. I want XMOS board as grandmaster and linux as slave. I'm trying to force it both by setting asCapable=0 on linux_ptp and by setting priority1=255 on linux.

The problem is that the linux_ptp isn't going in SLAVE state.
This is the log on linux console:
ptp4l[21768.947]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[21768.947]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[21771.968]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[21771.968]: selected local clock 080027.fffe.9452ef as best master
ptp4l[21771.968]: assuming the grand master role
ptp4l[21772.637]: port 1: new foreign master 002297.fffe.801164-1
ptp4l[21774.438]: selected best master clock 002297.fffe.801164
ptp4l[21774.438]: running in a temporal vortex
ptp4l[21774.438]: port 1: MASTER to UNCALIBRATED on RS_SLAVE

So it seems that linux sees XMOS as grandmaster clock and that its BMCA says to go in SLAVE state, but it stays in UNCALIBRATED state.
Does anyone know why?

After the previous log I see this on the linux console:
ptp4l[22983.136]: PI servo: sync interval 0.125 kp 0.187 ki 0.000435
ptp4l[22983.662]: port 1: delay timeout
ptp4l[22983.663]: delay filtered 137997 raw 151988
ptp4l[22983.700]: clock set to delete leap second at midnight (UTC)
ptp4l[22984.488]: rms 1600335662386366464 max 1600335662429898752 freq +100000000 +/- 0 delay 137997 +/- 0
ptp4l[22984.662]: port 1: delay timeout
ptp4l[22984.663]: delay filtered 136499 raw 119366
ptp4l[22985.390]: rms 1600335662286817280 max 1600335662330336768 freq +100000000 +/- 0 delay 136499 +/- 0
ptp4l[22985.663]: port 1: delay timeout
ptp4l[22985.663]: delay filtered 137997 raw 183524
ptp4l[22986.291]: rms 1600335662187285504 max 1600335662230871808 freq +100000000 +/- 0 delay 137997 +/- 0


Is that of any help?
I think it could be a problem with some settings but I didn't find anything useful.
etori90
Member++
Posts: 26
Joined: Thu Sep 05, 2019 6:49 am

Postby etori90 » Sun Sep 20, 2020 9:37 pm

Which PTP layer you use? I didn't try UDP/IP but 2layer worked well for setting master or slave.
I came back here again because of ascapable
one boards as master, other as slave and I can't see synced pps
Can't process msg because of ascapable. Did you have same problem?
nick
Member++
Posts: 25
Joined: Tue Jan 07, 2020 10:35 am

Postby nick » Mon Sep 21, 2020 12:46 pm

I tried only with layer 2. After some attempts I noticed that linux goes in SLAVE state after some time (about 20-30 seconds). And then it returns in UNCALIBRATED state. I think it's because of synchronization accuracy.
Did you notice the same behaviour? Do you have an interface that allows using hardware timestamping on linux?

Sorry, but I didn't try with two XMOS boards.
Can you set DEBUG_PRINT_AS_CAPABLE in gptp.xc file and see if it prints "asCapable = 1" in the xscope monitor?
etori90
Member++
Posts: 26
Joined: Thu Sep 05, 2019 6:49 am

Postby etori90 » Mon Sep 21, 2020 1:06 pm

I used lancard supporting hardware timestamping , but it doesn't matter i think. It worked on software option.
a month ago I checked linux ptp machine synchronizing to xmos boards, but i modified something and it doesn't work now.

So I checked something.


(ptp_recv) function of (gptp.xc)
case PTP_PDELAY_RESP_FOLLOW_UP_MESG:

we might need to set ascapable to 1 by entering set_ascapable function.

but during exchanging pdelay response packet. I found blocked by (received_pdelay_id[src_port] == ntoh16(msg->sequenceId))
you check this part once
when equal I checked changing state (xmos board state changing master to slave)

At wireshark, check whether linux ptp sends pdelay req then xmos boards reply instantly

only you and I doing this. Let's go together.
Best regards

Who is online

Users browsing this forum: No registered users and 4 guests