linuxptp-users

[Linuxptp-users] Non-zero correction field with linuxptp

[Harini K. <har...@gm...>]

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

Re: [Linuxptp-users] Non-zero correction field with linuxptp

[Richard C. <ric...@gm...>]

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

Re: [Linuxptp-users] Non-zero correction field with linuxptp

[Richard C. <ric...@gm...>]

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

Re: [Linuxptp-users] Non-zero correction field with linuxptp

[Harini K. <har...@gm...>]

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