th signals are absent and the clock goes into holdover based on its oscillator. For the oscillator holdover case, the tester measures the phase error over 1000 S and plots it against a mask that rises to 1 us after 1000 S. Once again, holdover tests should only be initiated following a period that allows the clock to settle down following setup. For accurate long-term tests, that should be up to 24 hours. Frankly, the testing of assisted clocks is not frequently executed. In some ways, these tests are sim- pler than the G.8273.2 case, but quite a few combinations of possible cases are not yet specified. This is because the assisted scenario has more contributing factors that are difficult to model and control. Another reason is that G.8273.4 is a much later document, SO the definition of more limits and cases may come with time. That is the case with the assisted clocks; now to look at the case of unassisted PTS clocks, which is probably a more realistic scenario to test against. Testing T-BC-P and T-TSC-P to G.8273.4 In the preceding section, G.8273.4 covered the cases of the PTP-aware clock with local assistance. This section, also based on G.8273.4, covers the case where there is only partial support from the network with no local time source. The Telecom Boundary Clock with partial support (T-BC-P) and Telecom Time Slave Clock with partial support (T-TSC-P) clocks also run G.8275.2 PTPoIP, and using a physical frequency source, such as SyncE or eSyncE, is optional. If SyncE is used as a frequency source, then the T-BC-P/T-TSC-P clock must implement an assist- ing clock that meets the clock requirements of G.8262 and the ESMC capabilities of G.8264. If a TDM signal is used as a frequency source, then it must meet the clock requirements of G.813 and the SSM requirements of G.781. This is as you would expect. The testing methodology is equivalent to the methodology described in the preceding section for testing according to the G.8273.2 recommendation for T-BC/T-TSC, SO the preceding Figure 12-19 is still valid 