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

Martin Burnicki martin.burnicki at burnicki.net
Fri Jan 29 08:45:55 EST 2016


Hello Net Monk,

NeT MonK wrote:
> I have subscribed to this list following this incident as far as it was the
> first of the few results of search in Google for three days ago.
> 
> On my linux platform of hundreds serveurs,  I had incident because of this,
> on servers which only  use of ptp.
> I have two sources grand master clock one I control (a meinberg appliance)
> and act as passive and the second is just a Cisco relaying the ptp stream
> from the market.
> 
> 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.
> 
> Am I the only one who suffered the loss of the utc_valid_flag in ptp stream
> ? And what appliance would behave like this ? As far I can tell my
> secondary meinberg appliance aside a few oscillator recalibration message
> in the console log behaved very nicely.
> 
> But I have no view of the primary master source and kind of hardware they
> use.

The time stamps sent in the PTP messages on the network are usually TAI,
not UTC. The PTP announce message contains a UTC offset field telling
the current time difference, and a flag indicating if the UTC parameter
is valid.

Currently the difference between TAI and UTC is 36 seconds, so if the
grandmaster sends no valid UTC offset, or utc_valid flag is not set,
then a client probably just evaluates the raw TAI time, and thus its
time steps by 36 seconds until it receives a PTP announcement message
with valid UTC parameters again.

I don't know the details of your PTP setup, but we (at Meinberg) have
already had another customer some time ago where a Cisco switch acting
as boundary clock didn't send UTC data reliably when the grandmaster was
switched.

So eventually you should contact Cisco and see if there is an update
available for the switch where this is fixed.

Martin



More information about the time-nuts mailing list