cancel
Showing results for 
Search instead for 
Did you mean: 

PTP offload H7: one-step timestamp from HW?

LCE
Principal II

Heyho,

a few questions to those who already used the PTP offload function (not via IP / UDP, but PTP directly over ethernet, MAC packet type 0x88F7), which can auto-generate SYNC and DelayRequest messages:

1) As this feature does not auto-generate FollowUp messages (so no "two-step" timestamp), I assume that the timestamp sent with the auto-generated SYNC message is the "exact timestamp" when the packet leaves the STM32's MAC, so that 2-step is absolutely not required ?

2) And was this ever tested at STM? -->> examples...

3) Why was no automatism created for Announce messages? (Okay, these are timing-wise not important)

Using the HW would greatly reduce speed and code size, because LWIP would be completely unused for PTP, and my modified PTPd could be reduced greatly (much less "manual" packet processing)

Anyway, one more request for example source code!

@STea please, or whoever ...

24 REPLIES 24
LCE
Principal II

@Pavel A. I'm not sure what you mean.

From the pure timestamps, the path delays are not so easy to see, I can only rely on PTPd's algorithms, which I also use for the offload version.

Mean Path Delay:

~ 21 µs with offload

~ 29 µs with PTPd over lwIP / IPv4 / UDP

 

Anyway, I found the bug and have the audio streaming running again (it was taking care of PTPd's messaging and blocked itself in offload mode).

BUT... now the audio streaming makes the PTP sync even worse with PTP offload than with PTPd over lwIP / IPv4 / UDP.

Even at about half of max audio data rate (max is ~50 Mbps) PTP offload sync is always off at ~25 Mbps, getting back in sync only when audio streaming stops. Even with lucky packet filters.

Very frustrating, all for nothing it seems right now... Let's see what I can do. 

LCE
Principal II

now the audio streaming makes the PTP sync even worse with PTP offload

My mistake, slave's SYNC interval was not set correctly. Now reading it from each SYNC message.

Dear ST, there are still a few things I'd like to know...

Unmark the thread as solved if you want them to look?

LCE
Principal II

OLS doesn't even read their own ref manuals correctly...

And no comment on getting more / any Synopsis documentation.

Maybe anybody else from ST who already helped on other PTP related threads?

@OlivierK 

@STea 

@STackPointer64 

@Christophe Guibout 

 

 

LCE
Principal II

Status:

1) Without PTP offload -> PTP via lwIP / UDP is rock solid. Lucky packet filtering vs packet delay variation. This an absolute must when traffic goes up with even "medium" traffic.

2) With PTP offload: is one-step only, and right now I doubt that the SYNC messages really send out a hardware timestamp. With the same clock correction function as in 1), synchronization is good, but only until traffic goes up, then it 's getting horribly bad.
I already wasted too much time with the PTP offload, no time to verify my assumptions.

We need more documentation & clarification!

So, please, dear...

@OlivierK 

@STea 

@STackPointer64 

@Christophe Guibout