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

Martin Burnicki martin.burnicki at burnicki.net
Mon Feb 1 10:49:52 EST 2016


NeT MonK wrote:
> On Fri, Jan 29, 2016 at 3:29 PM, Chris Caudle <chris at chriscaudle.org> wrote:
> 
>> On Fri, January 29, 2016 1:32 am, NeT MonK wrote:
>>> As a side effect of those glitch in the GPS matrix, the utc_valid_flag
>> was
>>> not anymore set in the stream of the primary master clock, just before my
>>> secondary starts to become active (loss of primary stream) which leads to
>>> linux server  ptp slave to readjust of +36 seconds and jump backward -36
>>> seconds as far as the flags was coming back.
>>
>> The difference between UTC and TAI is 36 seconds.
>>
>> Are you running ptpd or linuxptp on your Linux servers?
>> It sounds like the ptp agent running on your servers interpreted the lack
>> of UTC valid flag to mean that the timestamps were now in TAI, so the
>> server kernel applied the TAI to UTC offset to the time received via PTP.
> 
> 
> Dear Chris,
> 
> I run sfptpd  which is a fork of linux ptpd daemon adapted to solarflare
> network adapter.
> I will have to fine tune it in order to be more resilient in such scenario.

Hm, the task of the PTP slave software is to discipline the PC's *UTC*
time, 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.

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.

> But i guess it's not very often the gps system as such incident.

Of course this is not primarily related to GPS. I'd expect is could
under some other confitions that the utc_valid flag is cleared.

Please not with GPS and UTC correction it's somewhat similar. The GPS
satellites also provide the UTC correction data set, but if you start a
GPS receiver in cold boot mode, i.e. without any satellite data already
saved in non-volatile memory, the GPS receiver is unable to convert GPS
time to UTC, until it has received a UTC parameter set from the
satellites. This can take up to 12 minutes since these parameters are
sent repeatedly every 12 minuts.

Without UTC correction parameters the receiver can be used for
navigation, but not for timing. If a timing GPS receiver would declare
itself "synchronized" in this state then the time which is output would
be GPS time only, not UTC, and a time discipline software which accepted
the time from the GPS in this state would also set the PC system time
wrong by 17 seconds, since this is the current difference between UTC
and GPS system time.

Martin



More information about the time-nuts mailing list