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 <netm...@netmonk.org> wrote: > > On Fri, Jan 29, 2016 at 2:45 PM, Martin Burnicki < > martin.burni...@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
