ccuracy under high-stress traffic situations. For reference, there is more information on testing these clocks in Appendixes A.4 and B.4 of ITU- T G.8273 as well as the equipment limits that are specified in G.8273.3. Note that to provide the best performance, the T-TC needs connection to a form of physical fre- quency, and of course, the most likely choice to provide that signal is SyncE or eSyncE. The reason this signal is needed is the same reason that a tester needs it. The T-TC needs to measure the transit time that the PTP message spends resident in the clock, and to do that its oscillator needs to be ac- curate. Consequently, G.8273.3 recommends that the T-TC should be frequency synchronized to an external frequency reference to remove errors due to oscillator inaccuracy. As with the T-BC recommendations, G.8273.3 specifies that a T-TC can perform at either Class A or Class B level of performance, with the latest revision adding a Class C. To achieve the level of Class C, T-TC clocks can only be used in combination with eSyncE clocks (from G.8262.1). Many of the values used to define the classes of performance are the same as those for the T-BC case. The following represents a synopsis of the performance tests of a T-TC clock from G.8273.3: Noise generation: The tester applies an ideal signal (PTP with SyncE), sends messages out a master port, receives the return signal on a slave port, and measures the TE introduced by the time signal passing through the DUT. The tester measures the 2wayTE (see Chapter 9) and confirms a pass/fail against the specified max|TE| T-TC clock limit, such as 100 ns for Class A and 70 ns for Class B. Currently, the value for Class C is not specified. The tester also calculates the cTE (averaged over 1000 s) and the MTIE for the (filtered) dTE. Each of these calculated values is used to measure compliance against class (A, B, or C) for noise generation. For cTE, Class A is +50 ns, Class B is +20 ns, and Class C is +10 ns when av- eraged over 1000 S (the same as for the T-BC case).