break is immediately upstream of the DUT, and SO it is the isolated node). Many operators like to perform holdover tests because they would like to know how the network and the network clocks will perform when faced with outages in the timing signal from their references. One additional special case that needs mentioning is the testing of the assisted partial timing support (APTS) network topology, especially in the case of holdover (failure of the local reference clock). When the DUT is connected to its primary source, it is much like a T-GM or a T-BC with zero hops to the GM. When it loses that primary source of time, it is much like a T-BC on a partial timing sup- port (PTS) network. The only assistance it has is the compensation mechanism to correct for the measured static asymmetry. Operators considering this option obviously want to test how well this approach works on a network that very closely matches their likely deployment. Now that you have seen the basic cases of testing nodes end to end in a network, it is time to con- sider the performance of the clocks as standalone entities and verify the equipment limits. 12.3.1 Testing Frequency Clocks in a Packet Network Until this point in the chapter, the testing has been about the performance of the timing signal in the end-to-end scenario-what the timing signal looks like after emerging from the last link in the chain. But the end-to-end performance is very much reliant on the performance of the nodes that make up that network, or what the ITU-T calls equipment limits. The main clock of interest in these packet-based deployments is the SyncE (or eSyncE) clock, SO the following section covers the testing of the metrics and behavior for those clocks. Testing EEC and eEEC SyncE Clocks The good thing about testing SyncE clocks (EEC and eEEC) is that it is somewhat less confusing than the case with TDM-type interfaces, and there are not as many recommendations to follow. For- tunately, most operators prefer SyncE as a frequency transport rather than some altern