[time-nuts] GPS jumps of -13.7 us?

[Chris Caudle]

On Mon, February 1, 2016 9:49 am, Martin Burnicki wrote:
> Hm, the task of the PTP slave software is to discipline the PC's *UTC*
> time,

Typically, but I don't think there is a requirement to discipline the UTC
system time.  You could maintain a separate PTP time domain, or run the
system clock as TAI (or GPS) and let the system software convert as
needed.
But of course flexibility offers the opportunity to interpret incorrectly...

> but this sounds like it even accepts the time from the PTP
> (grand)master if the master has *not* set utc_valid flag to 1, i.e. the
> master tells the slave it has no idea about the correct UTC time, but
> the slave accepts the uncorrected time anyway.

I think it might be a slightly more subtle error.  It appears that the
master cleared the flag to indicate "this time is no longer correctly and
fully synchronized to UTC time," no more and no less.  It appears that the
slave interpreted the lack of set flag to mean "this time is the correct
TAI timestamp," which is obviously not the same thing as "this time is not
fully synchronized to UTC."

> Maybe in this case the slave software should rather generate an error
> and discard the PTP source, instead of accepting and using the pure TAI
> time, which causes the PC's system time to go wrong.

Yes, some variation of setting an error flag would be more appropriate.
It seems that a more reliable method would have a UTC_Valid flag, and a
separate field to indicate that the time stamp should be interpreted as
UTC, GPS, or TAI, or unsynchronized time (i.e. possibly syntonized but not
set from the accepted epoch).  In that case the UTC_valid flag should
probably really be a "timestamp_valid" flag, or "timesource_synchronized"
flag, some kind of indication that the source of the timestamp is thought
to meet the standard implied by the source field.


-- 
Chris Caudle