NeT MonK wrote: > On Fri, Jan 29, 2016 at 3:29 PM, Chris Caudle <[email protected]> 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
