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

[r1ftrouter]

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. 

//r1ftrouter

> 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.
>