linuxptp-users

[Linuxptp-users] phc2sys with REALTIMECLOCK

[Christian L. <chr...@ch...>]

Hi,

I have a boundary clock with ports eth0 and pru10:

ptp4l config (most important params shown):

[eth0]
boundary_clock_jbod 1

[pru10]
boundary_clock_jbod 1

GMC is connected to pru10, nothing connected to eth0. I start ptp4l and phc2sys:
ptp4l -f <cfg>
phc2sys -arm

Everything goes well:

phc2sys[1530231.490]: reconfiguring after port state change
phc2sys[1530231.491]: pru10: UNCALIBRATED -> new state SLAVE
phc2sys[1530231.491]: selecting eth0 (MASTER) for synchronization
phc2sys[1530231.492]: dst_cnt: 1

CLOCK_REALTIMEis finally added to list of dst clocks (line 477 of phc2sys.c)

phc2sys[1530231.493]: selecting CLOCK_REALTIME for synchronization:
phc2sys[1530231.494]: selecting pru10 (SLAVE) as the master clock

ptp4l[1530234.487]: master offset         20 s2 freq   -9940 path delay         9

phc2sys is syncing CLOCK_REALTIME and eth0 as expected
phc2sys[1530235.310]: CLOCK_REALTIME phc offset     -2833 s0 freq   -9911 delay   3091
phc2sys[1530236.360]: eth0 phc offset      -100 s0 freq   -9882

--------
Now I disconnect GMC. I would expect that the last sync source is taken and this last sync source syncs also the CLOCK_REALTIME.

phc2sys[1530250.221]: reconfiguring after port state change
phc2sys[1530250.221]: pru10: SLAVE -> new state MASTER
phc2sys[1530250.221]: selecting pru10 (MASTER) for synchronization
phc2sys[1530250.221]: selecting eth0 (MASTER) for synchronization
phc2sys[1530250.222]: dst_cnt: 2
phc2sys[1530250.222]: no source, selecting pru10 (SLAVE aka MASTER) as the default clock

ok. So far. But the CLOCK_REALTIME is not added to list of dst clocks! As a consequence, CLOCK_REALTIME is not synced anymore.

phc2sys[1530254.251]: eth0 phc offset    -89483 s0 freq   -9955
phc2sys[1530256.350]: eth0 phc offset    -39106 s0 freq  +34863

Is this the intended behaviour?

I see the problem here:

static void reconfigure(struct node *node)
{
....
                if (dst_cnt > 1 && !src) {
                                if (!rt || rt->dest_only) {
                                                node->master = last;
                                                /* Reset to original state in next reconfiguration. */
                                                node->master->new_state = node->master->state;
                                                node->master->state = PS_SLAVE;
                                                if (rt)
                                                                rt->state = PS_SLAVE;
                                                pr_info("no source, selecting %s as the default clock",
                                                                last->device);
Here we return if last sync source is taken, but CLOCK_REALTIME is not added to node->dst_clocks!...
                                                return;
                                }
                }
                if (src_cnt > 1) {
                                pr_info("multiple master clocks available, postponing sync...");
                                node->master = NULL;
                                return;
                }
                if (src_cnt > 0 && !src) {
                                pr_info("master clock not ready, waiting...");
                                node->master = NULL;
                                return;
                }
                if (!src_cnt && !dst_cnt) {
                                pr_info("no PHC ready, waiting...");
                                node->master = NULL;
                                return;
                }
                if ((!src_cnt && (!rt || rt->dest_only)) ||
                    (!dst_cnt && !rt)) {
                                pr_info("nothing to synchronize");
                                node->master = NULL;
                                return;
                }
                if (!src_cnt) {
                                src = rt;
                                rt->state = PS_SLAVE;
                } else if (rt) {
                                if (rt->state != PS_MASTER) {
                                                rt->state = PS_MASTER;
                                                clock_reinit(node, rt, rt->state);
                                }
.. here we add the CLOCK_REALTIME in the normal sync case:
                                LIST_INSERT_HEAD(&node->dst_clocks, rt, dst_list);
                                pr_info("selecting %s for synchronization", rt->device);
                }
                node->master = src;
                pr_info("selecting %s as the master clock", src->device);
}

Best regards, Chris

Re: [Linuxptp-users] phc2sys with REALTIMECLOCK

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

On Fri, Apr 17, 2020 at 06:47:57AM +0000, Christian Leeb wrote:
 
> ok. So far. But the CLOCK_REALTIME is not added to list of dst clocks! As a consequence, CLOCK_REALTIME is not synced anymore.
> 
> phc2sys[1530254.251]: eth0 phc offset    -89483 s0 freq   -9955
> phc2sys[1530256.350]: eth0 phc offset    -39106 s0 freq  +34863
> 
> Is this the intended behaviour?

I'm not 100% sure what was intended.  This program grew over time, but
I can certainly come up with an explanation for this behavior...

Originally, the phc2sys program did something very simple, namely just 
synchronizing the system clock to a single PHC (or the reverse).

When the program grew to support multiple PHCs, then it had to
determine which PHC was the slave and synchronize everything else to
it.

But if no PHC in the slave state, what then is the correct choice?

The best choice might be to simply let the system time act as a free
running clock.  After all, perhaps the motherboard has a quartz
crystal and the PHC has a simple R/C circuit.  The system clock could
very well have better holdover qualities than the PHC.

So you might not like this explanation, but there it is.

Thoughts?

Thanks,
Richard

Re: [Linuxptp-users] phc2sys with REALTIMECLOCK

[Christian L. <chr...@ch...>]

Hi Richard,

Here are my thoughts.
phc2sys is a piece of code with some twists 😊

1) Regarding "After all, perhaps the motherboard has a quartz crystal and the PHC has a simple R/C circuit.  The system clock could very well have better holdover qualities than the PHC.": 
	- I'd rather claim that typically all clocks of a SoC are derived from a single crystal oscillator. For our TI Sitara based HW this is certainly the case.
	- with -r / -rr it can be already controlled if system clock is a possible sync dest/source.
2) If the system clock is eligible a sync destination I would claim that it should also get synced if there is no source. This would be consistent as also all PHCs are kept in sync.

Best regards, Chris

-----Original Message-----
From: Richard Cochran <ric...@gm...> 
Sent: Samstag, 18. April 2020 05:10
To: Christian Leeb <chr...@ch...>
Cc: lin...@li...; Henrik Pind <hen...@se...>; Erdahl, Michael <m-e...@ti...>
Subject: Re: [Linuxptp-users] phc2sys with REALTIMECLOCK

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Fri, Apr 17, 2020 at 06:47:57AM +0000, Christian Leeb wrote:

> ok. So far. But the CLOCK_REALTIME is not added to list of dst clocks! As a consequence, CLOCK_REALTIME is not synced anymore.
>
> phc2sys[1530254.251]: eth0 phc offset    -89483 s0 freq   -9955
> phc2sys[1530256.350]: eth0 phc offset    -39106 s0 freq  +34863
>
> Is this the intended behaviour?

I'm not 100% sure what was intended.  This program grew over time, but I can certainly come up with an explanation for this behavior...

Originally, the phc2sys program did something very simple, namely just synchronizing the system clock to a single PHC (or the reverse).

When the program grew to support multiple PHCs, then it had to determine which PHC was the slave and synchronize everything else to it.

But if no PHC in the slave state, what then is the correct choice?

The best choice might be to simply let the system time act as a free running clock.  After all, perhaps the motherboard has a quartz crystal and the PHC has a simple R/C circuit.  The system clock could very well have better holdover qualities than the PHC.

So you might not like this explanation, but there it is.

Thoughts?

Thanks,
Richard

Re: [Linuxptp-users] phc2sys with REALTIMECLOCK

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

On Mon, Apr 20, 2020 at 07:58:53AM +0000, Christian Leeb wrote:

> 	- I'd rather claim that typically all clocks of a SoC are derived from a single crystal oscillator. For our TI Sitara based HW this is certainly the case.

I can only say, well done!  However, most ARM boards I've seen aren't
this careful.  The MAC is not always part of the SoC.  Also, there is
no guarantee that a MAC on a SoC is in the same clock domain as the
rest.  I won't even mention PC systems.

But my point was not to claim the MAC clocks are generally worse than
system clocks.  Rather, there must be some sort of default behavior,
and the choice of that default is arbitrary.  There is no clear "best"
alternative here.

> 	- with -r / -rr it can be already controlled if system clock is a possible sync dest/source.
> 2) If the system clock is eligible a sync destination I would claim that it should also get synced if there is no source. This would be consistent as also all PHCs are kept in sync.

The default behavior is what it is, and it will stay that way simply
because changing it willy-nilly is user unfriendly.

The real problem is the lack of any means for users to configure the
desired behavior.  Patches are always welcome...

Thanks,
Richard