cuit and uses that to become the ACR clock master. Remember, this is a service clock on only a single interface; the CEM node would never use the customer frequency to drive the (network) clock on the entire CEM node. Another AC on the same router could use a different clock from another customer. Still other ACs could reverse the clock direction and use the network clock-which means the customer equipment would have to receive the clock as is shown in Figure 9-5. Regarding performance, the recovery of accurate frequency by ACR is susceptible to PDV. If the delay caused by the packet network is constant, the frequency of arrival of packets at the destination node is not affected by the network. There will be a lag in the phase of the recovered clock due to the delay through the network, but it will not suffer frequency or phase wander at the slave end. On the other hand, if the delay varies, the clock recovery process on the slave may interpret that as a change in phase or frequency of the master clock (which it is not). The big advantage of ACR is that every interface can run a different (service) clock. Therefore, ACR is a very good tool for a third-party circuit provider to transparently carry a different service clock from many customers over their shared infrastructure that is still using its own network clock. But ACR does have some limitations, not the least being that it might not scale SO well for very large and dense installations of TDM circuits. Also, the mechanism for locking and getting the clock to settle is somewhat looser and less deterministic than when compared to any physical method. This is because ACR is fundamentally an averaging process over time. For this reason, after an ACR clock is provisioned and starts recovering the clock, a waiting period of 15-20 minutes is recommended before measuring the maximum time interval error (MTIE) for the recovered clock. This behavior is documented in Appendix 2 of ITU-T G.8261, "Timing and synchronization aspects in packet networks." Also, maintaining 