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

r1ftrouter r1ftrouter at hushmail.com
Sat Jan 30 12:46:33 UTC 2016

Cisco as a boundary clock is susceptible to error. Ive seen under conditions of cpu-bound high traffic load (bgp event, high levels of broadcast) the ptp process has a lower interrupt priority on the scheduler and therefore prone to more jitter when it comes to acting as a master. As the Cisco devices do not accept a pps input one is better off using a server which does for greater master clock stability, or going to what device recieves your signal from GPS antennae. 

Dont expect too much from TAC on this btw. 


> On Jan 29, 2016, at 3:05 PM, NeT MonK <netmonk at netmonk.org> wrote:
> On Fri, Jan 29, 2016 at 2:45 PM, Martin Burnicki <
> martin.burnicki at burnicki.net> wrote:
>> Hello Net Monk,
>> ...
>> 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
> Hello Martin,
> Thank you for your reply and details, this is also what i already stated on
> my incident report.
> My ptp client applied the utc offset when the flag disappeared which lead
> to this jump forward and backward.
> A call is already opened to Cisco and they are coming in coming weeks for
> auditing the ptp infra.
> Regards.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the Time-nuts_lists.febo.com mailing list