|
From: Miroslav L. <mli...@re...> - 2013-04-26 13:30:37
|
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
|