linuxptp-users

[Linuxptp-users] PTP master slewing to other network time

[Dave C. <dav...@un...>]

Hi,

I have a group of devices successfully keeping their system clocks
synchronized on a local network using ptp4l. The master is left up to the
bmc arbitration and as all the devices are basically the same, the chosen
master comes down to the device MAC address. I'd like the master time to be
'roughly' UTC, so want to slew/step whoever the current master is to make
this happen.
There's already a process on each device that gets the current time via NTP
or HTTP and so I'd like to make it so that the PTP master accepts times
from this process and slews/steps it's clock appropriately. Devices which
are currently slaves would simply ignore/discard the attempts to set their
time and stay locked to the master.
Is there already a mechanism I can use to do this that I've missed, or
should I try adding one to ptp4l or possibly phc2sys?

Thanks

Dave Craig.

Re: [Linuxptp-users] PTP master slewing to other network time

[Miroslav L. <mli...@re...>]

On Wed, Aug 21, 2013 at 11:23:41AM +0100, Dave Craig wrote:
> There's already a process on each device that gets the current time via NTP
> or HTTP and so I'd like to make it so that the PTP master accepts times
> from this process and slews/steps it's clock appropriately. Devices which
> are currently slaves would simply ignore/discard the attempts to set their
> time and stay locked to the master.
> Is there already a mechanism I can use to do this that I've missed, or
> should I try adding one to ptp4l or possibly phc2sys?

Is that with hw or sw time stamping?

You can check if the local PTP port is in the master state with
pmc -u -b 0 'GET PORT_DATA_SET'. If the hw time stamping is used, you
will need to also synchronize the PTP hardware clock from the system
clock with the phc2sys program.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] PTP master slewing to other network time

[Dave C. <dav...@un...>]

Hi Miroslav,

Thanks for the quick response.

On Wed, Aug 21, 2013 at 12:29 PM, Miroslav Lichvar <mli...@re...>wrote:

> On Wed, Aug 21, 2013 at 11:23:41AM +0100, Dave Craig wrote:
> > There's already a process on each device that gets the current time via
> NTP
> > or HTTP and so I'd like to make it so that the PTP master accepts times
> > from this process and slews/steps it's clock appropriately. Devices which
> > are currently slaves would simply ignore/discard the attempts to set
> their
> > time and stay locked to the master.
> > Is there already a mechanism I can use to do this that I've missed, or
> > should I try adding one to ptp4l or possibly phc2sys?
>
> Is that with hw or sw time stamping?
>
I'm using sw timestamping.


> You can check if the local PTP port is in the master state with
> pmc -u -b 0 'GET PORT_DATA_SET'.

Although I can get the master state and then choose to set the system clock
based on that, it means that I'd be writing very similar code to the servo
code of PTP inside my NTP process. It currently just calls settimeofday,
but I'd rather it slewed to the new time more gracefully. I wondered if
having that work done inside ptp4l would be tidier? In the master state the
clock servo would be accepting changes over pmc and in the slave state
ignoring it.

Thanks

Dave

Re: [Linuxptp-users] PTP master slewing to other network time

[Miroslav L. <mli...@re...>]

On Wed, Aug 21, 2013 at 12:46:01PM +0100, Dave Craig wrote:
> On Wed, Aug 21, 2013 at 12:29 PM, Miroslav Lichvar <mli...@re...>wrote:
> > You can check if the local PTP port is in the master state with
> > pmc -u -b 0 'GET PORT_DATA_SET'.
> 
> Although I can get the master state and then choose to set the system clock
> based on that, it means that I'd be writing very similar code to the servo
> code of PTP inside my NTP process. It currently just calls settimeofday,
> but I'd rather it slewed to the new time more gracefully. I wondered if
> having that work done inside ptp4l would be tidier? In the master state the
> clock servo would be accepting changes over pmc and in the slave state
> ignoring it.

You could use the adjtime system call instead of settimeofday to
adjust the clock slowly and not in one step.

I guess there could be a private pmc command to feed the servo
manually, but it would have to be called periodically in the sync
interval as the servo can't slew the clock by a specified offset with
just one point. It's a feedback loop.

Why not use ntpdate or a regular NTP daemon instead?

-- 
Miroslav Lichvar

Re: [Linuxptp-users] PTP master slewing to other network time

[Dave C. <dav...@un...>]

On Wed, Aug 21, 2013 at 1:03 PM, Miroslav Lichvar <mli...@re...>wrote:

> On Wed, Aug 21, 2013 at 12:46:01PM +0100, Dave Craig wrote:
> > On Wed, Aug 21, 2013 at 12:29 PM, Miroslav Lichvar <mli...@re...
> >wrote:
> > > You can check if the local PTP port is in the master state with
> > > pmc -u -b 0 'GET PORT_DATA_SET'.
> >
> > Although I can get the master state and then choose to set the system
> clock
> > based on that, it means that I'd be writing very similar code to the
> servo
> > code of PTP inside my NTP process. It currently just calls settimeofday,
> > but I'd rather it slewed to the new time more gracefully. I wondered if
> > having that work done inside ptp4l would be tidier? In the master state
> the
> > clock servo would be accepting changes over pmc and in the slave state
> > ignoring it.
>
> You could use the adjtime system call instead of settimeofday to
> adjust the clock slowly and not in one step.
>
That's probably the approach I'll take. I was concerned about a race
between calling pmc to find out if the local device was the master and
actually setting the time, but it's by far the simplest solution and the
chances of a race are small and it's effects fairly minor.


> I guess there could be a private pmc command to feed the servo
> manually, but it would have to be called periodically in the sync
> interval as the servo can't slew the clock by a specified offset with
> just one point. It's a feedback loop.
>
The NTP process gets the time fairly regularly so this wouldn't be a
problem.


> Why not use ntpdate or a regular NTP daemon instead?
>
Unfortunate legacy reasons :-(

Thanks again for your advice,

Dave