On Wed, Jun 28, 2017 at 11:38:48PM +0200, Boris Boucher wrote:
> But, in a global system that is powered up, the GPS helped master
> clock will take some some time to start, eventually more time than
> my SERVER machine. In between the SERVER will assume grand master
> role and start broadcast the wrong time (because its utc offset
> knowledge is old).
As long as currentUtcOffsetValid=0, then the behavior of the SERVER is
correct according to the standard.
Still, that is little consolation to you, when your clients ignore the
currentUtcOffsetValid flag.
> So, on one hand, we face the risk of having an offset error each
> time the system is started, on the other hand, we have e very little
> change of starting up the system just after a leap second update and
> have the wrong time until the GPS helped master clock is available.
> From my point of view, having a risk of temporary false time after
> each startup is more problematic.
I disagree. If I were to implement this "magic" saving of the offset,
then it would appear to work, even though it is in fact broken. Then
users would rely on this, until the day comes when someone hits our
latent leap second bug.
I prefer to force users to come to grips with their configuration WRT
leap second handling early on, rather than waiting until the rare
event causes very unpleasant surprises.
> By the way, this configuration option seams not to be documented
> (never seen it before). I just looked in the source code to retrieve
> it. But I didn't see it as a command line switch in the code.
This is a new option, post version 1.8 but in the latest git head.
From 33e62f992542ac5ce6bdbb8ae6c34dec7011b543 Mon Sep 17 00:00:00 2001
From: Viliam Lejcik <viliam.lej...@kistler.com>
Date: Tue, 17 Jan 2017 18:25:26 +0100
Subject: ptp4l: Make UTC offset configurable.
Currently UTC offset is defined as a constant - CURRENT_UTC_OFFSET, and if
a leap second is added, that constant is no longer valid. Ptp4l was
updated to read the UTC offset from configuration instead.
Signed-off-by: Viliam Lejcik <viliam.lej...@kistler.com>
Thanks,
Richard
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
