PTP Alarms

Enhanced PTP User Guide (UG1602)

Document ID
UG1602
Release Date
2022-10-18
Revision
1.0 English

The following list identifies all PTP alarms generated by sfptpd. Active alarms will be present in the /var/lib/sfptpd/topology file and in state files within this directory.

Version 3.3.0.1007 sfptpd will log changes to alarm states in the sfptpd message log.

no-sync-pkts

PTP Sync packet(s) are not being received. From a tcpdump pcap file, identify if packets are actually being received at the PTP interface.

Sync/FollowUp pairs have sequential sequence ID values. If some or all Sync packets are missing, the user should check these are being generated by the upstream master clock.

no-follow-ups

PTP FollowUp packet(s) are not being received. From a tcpdump pcap file, identify if packets are actually being received at the PTP interface.

When the upstream master is using 2-step synchronization it will send a FollowUp packet for every Sync packet sent. Sync/FollowUp pairs have sequential sequence ID values. If some or all FollowUp packets are missing, the user should check these are being generated by the upstream master clock.

The counters in the /var/lib/sfptpd/stats-<clock id> files will identify the number of FollowUp messages received. There should be the same number of FollowUps as there are Sync messages received.

no-delay-resps

The slave will send periodic Delay-Request messages to the upstream master clock. The master clock should respond to each with a Delay-Response message having the same sequence ID value as the request.

From a tcpdump pcap file, identify if packets reported as missing are actually being received at the PTP interface.

If some or all Delay-Request packets are missing, the user should check the master clock configuration or consult the master clock vendor.

If Delay-Response messages, reported as missing, are actually being received on the PTP interface, check that the requestingSourcePortidentity and requestingSourcePortID values in the response message match the clockIdentity and sourcePortID values in the corresponding request message. It these values do not match, the response messages will be ignored.

no-pdelay-resps

When using the peer-to-peer delay method this alarm identifies that PDelay-Response messages are not being received for all PDelay-Request messages sent by the slave server.

no-pdelay-resp-follow-ups

When using the peer-to-peer delay method this alarm identifies that PDelay-Response-FollowUp messages are not being received by the sfptpd slave.

no-tx-timestamps

Identifies that sfptpd is not able to timestamp outgoing packets.

no-rx-timestamps

Identifies that sfptpd is not able to recover adapter timestamps for received PTP packets.

no-interface

In a bond, there are no slave interfaces available.

clock-ctrl-failure

An instance or clock servo is unable to control a clock and attempts to control it result in errors.

pps-no-signal

sfptpd is unable to detect any incoming PPS signal. Check that the upstream clock is generating the PPS signal. Check that PPS cable is connected to the PPS INPUT on the Solarflare adapter.

pps-seq-num-error

sfptpd is receiving PPS pulses, but reports missing or unexpected PPS sequence numbers. Ensure the driver and firmware being by the adapter are up to date. If the issue persists, run the sfreport script and return the HTML output along with the sfptpd stats log output to support-nic@xilinx.com.

pps-bad-signal

sfptpd has detected an invalid PPS period i.e. the measured PPS period is too long to be a pulse because it exceeds 1 second.

no-time-of-day

sfptpd is not detecting a time-of-day signal. This is normally seen when running sfptpd in one of the supported NTP/PPS modes. Time-of-day is the time supplied by the NTP server.