On Thu, Jul 27, 2017 at 10:17:51AM +0800, Phil Reid wrote:
> On 27/07/2017 05:02, Richard Cochran wrote:
> > On Wed, Jul 26, 2017 at 10:23:05AM +0200, Miroslav Lichvar wrote:
> > > On Mon, Jul 24, 2017 at 06:38:19PM +0200, Richard Cochran wrote:
> > > > + if ((c->tds.flags & UTC_OFF_VALID && c->tds.flags &
> > > > TIME_TRACEABLE) ||
> > > > + (c->tds.currentUtcOffset > c->utc_offset)) {
> > > > + pr_info("updating UTC offset to %d",
> > > > c->tds.currentUtcOffset);
> > > > + c->utc_offset = c->tds.currentUtcOffset;
> > >
> > > I'm wondering what will happen if a buggy/misconfigured master is
> > > briefly running with an UTC offset larger than the current offset.
> > > Will the slaves be stuck with the wrong offset?
> >
> > Jup.
> >
> > > Should be that ">" operator replaced with "!="?
> >
> > The original idea was that the hard coded offset will become obsolete,
> > but the new offset is always larger. If we see a larger offset, then
> > it is at least plausible.
> >
> > In contrast, a decreasing offset is always suspicious, because Earth's
> > rotational is slowing down, not speeding up.
> >
> Miroslav comment was re a buggy / misconfigured master.
> Which seems a valid point.
We trust the foreign masters based on their announce messages, and we
elect the GM based on their advertised values. Now, a buggy master
can ruin the time keeping on the slave in many ways, and we don't
second guess them. Of course, one could build in analysis and
heuristics in order to detect bad masters, but that is lots of work.
> Perhaps a warning is if the offset goes backwards.
There are two condition under which we accept the GM's TAI-UTC offset.
1. The GM advertises currentUtcOffsetValid=1 and timeTraceable=1.
In this case we believe the GM and accept the offset without any
further tests. (We also accept everything else the GM tells us.)
2. The GM says either !currentUtcOffsetValid or !timeTraceable, but
the advertised offset is greater than ours.
In this case we assume that time has gone on, and the hard coded
offset is simply out of date. Probably the GM has a more recent
idea of the correct offset. We do *not* accept smaller offsets
because this is physically impossible.
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
