source for the system because it is configured as a higher- priority input than port 2. However, it will revert to port 1 only after a wait to restore timer has ex- pired, and the default for this timer is 300 S or 5 minutes. The idea behind this timer is that the inter- face should demonstrate a period of fault-free operation before being relied upon as a source for the whole system. Engineers testing in a lab frequently tear their hair out wondering why the device is selecting fre- quency sources seemingly at random and never switching to the correct port when it should. This type of behavior is specified in G.781, and it is working exactly according to the recommendations. The cure for this is to configure revertive behavior and reduce the time to restore timer down to a reasonable minimum (for example 10 s), especially for lab and testing work. 12.5.1 Troubleshooting The preceding "Common Problems" section mentions that trying to write a detailed troubleshooting guide for a diverse range of implementations is a difficult task, as much of the behavior of a clock is affected by the design of its features. The approach to solving a timing problem can also be influ- enced by what sort of information is available by the software. Although these lessons learned are mostly based on the authors' substantial experience with Cisco routers (lesser SO for Linux running ptp41), some general principles apply universally. The following is the basic fault-finding methodology that Cisco suggests when helping customers who are trying to isolate a timing issue in their network: Step 1. Start with the PRTC source (likely a GNSS receiver) and confirm it is receiving good satellite signals (see the section "GNSS Receivers and Signal Strength" later in the chapter for detailed coverage of this topic). Step 2. Confirm that the T-GM is getting valid frequency, phase, and time signals from the PRTC. This is more likely to be an issue if the two functions are not combined into a single device-if they are separate devices, double-check 