The following list identifies all PTP alarms generated by
Active alarms will be present in the /var/lib/sfptpd/topology file
and in state files within this directory.
sfptpd will log changes to alarm states in the
sfptpd message log.
PTP Sync packet(s) are not being received. From a
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.
PTP FollowUp packet(s) are not being received. From a
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.
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.
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.
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.
When using the peer-to-peer delay method this alarm identifies that
PDelay-Response-FollowUp messages are not being received by the
sfptpd is not able to timestamp outgoing
sfptpd is not able to recover adapter timestamps
for received PTP packets.
In a bond, there are no slave interfaces available.
An instance or clock servo is unable to control a clock and attempts to control it result in errors.
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.
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
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.
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.