Re: [Linuxptp-devel] TAI vs UTC confusion

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

On Fri, Apr 26, 2013 at 03:02:05PM +0200, Libor Pechacek wrote:
> Hi,
> 
> While playing with a group of hosts using both hardware and software
> timestamping I've noticed a discrepancy in UTC/TAI usage.
> 
> With master using software timestamping (i.e. using system clock for
> timestamps) and slave having a PHC, using hardware timestamping and relying on
> phc2sys to sync system clock to PHC, all seems fine until I use phc2sys -w
> option.  At that point the slave system clock is exactly the 35 seconds behind
> master system clock.

This looks like a bug. The currentUtcOffset value should probably be
used only when the PTP_TIMESCALE flag is set. Can you please test it
with this patch?

--- a/phc2sys.c
+++ b/phc2sys.c
@@ -440,8 +440,9 @@ static int run_pmc(struct clock *clock, int timeout,
 
                        break;
                case TIME_PROPERTIES_DATA_SET:
-                       clock->sync_offset = ((struct timePropertiesDS *)data)->
-                               currentUtcOffset;
+                       if (((struct timePropertiesDS *)data)->flags & PTP_TIMESCALE)
+                               clock->sync_offset = ((struct timePropertiesDS *)data)->
+                                       currentUtcOffset;
                        if (((struct timePropertiesDS *)data)->flags & LEAP_61)
                                clock->leap = 1;
                        else if (((struct timePropertiesDS *)data)->flags & LEAP_59)

> Similarly, in reverse setup, master synchronizing system clock to PHC (PHC set
> as phc2sys slave here), PHC being broadcast to network by ptp4l, slave using
> software timestamping directly synchronizes its system clock to what is coming
> from network, the slave is again forced 35 seconds behind the master unless I
> use -w on the master.

I think that is working as expected. Without -w, the phc2sys running
on the PTP master doesn't know the currentUtcOffset value and sets the
PHC from the system clock without any TAI-UTC correction.

-- 
Miroslav Lichvar