当指针的正调整此数超过某一限度时，缓存器中的数据将取空。
为避免缓存器中的数据取空，缓存器将进行初始化，即把数据的读出点RA从Lmix点强制性的向右挪回到缓存器的中点。
同时，暂停从缓存器中读出数据，暂停时间=读取1个VC4（9x261字节）的时间，即要等到数据在缓存器中从Lmix写到中点时，再开始重新由RA点读出数据。
为保证设备从RA点输出的VC4信号流不会因此而中断，在暂停从缓存器中读取数据的期间，RA点将输出伪随机信息。
由此，设备将出现滑动误码现象，反应在该2M业务流出现突发误码。
（3）当CLKR和CLKW有较小的快速频差和相差时，RA点将在缓存器的Lmix-Lmax之间来回摆动，这时设备不进行AU-PTR指针调整，仅仅通过缓存器的存储空间L来容纳SDH设备间的频差和相差。
（4）当设备对接收的SDH信号流进行了一次指针负（正）调整后，本端设备在转发该路信号流之前，将在SDH信号帧中重新改写AU-PTR值，把原来接收到的AU-PTR值进行减1（加1）操作。
同时，本端设备需等待3帧时间后，才能再次进行指针调整。
（5）下游设备在接收到SDH信号流时，首先将本帧接收到的AU-PTR值与上一帧接收到的AU-PTR值进行对比，若不同则向网管报告该路信号流出现了指针调整性能事件。
注意：
此时反映的指针调整不是发生在本端，而是上游站点，只不过是在本端被检测出来罢了。
2.3网元M处
网元M为业务的终结站点，业务在该站点将从SDH信号流中解出、落地。
这里存在一个AU-PTR到TU-PTR的转化问题。
由于业务在中间站点是以VC4穿通的方式经过的，所以当SDH设备间时钟不一致时，适配功能是通过调整VC4的速率进行的，即通过AU-PTR调整的方式实现的，不会涉及到VC4内部TU-PTR的调整。
这样，在中间站点上的该路VC4中，TU-PTR依旧维持网元1赋予的初始值595，仅仅是指示VC4位置的AU-PTR在变动。
当SDH信号到达网元M后，网元M首先依据AU-PTR指针的值将该路VC4解出，即将该路VC4中插入或取出的填充字节进行逆操作（取出或插入），这样就恢复了该路VC4信号流的原始时钟特性（速率）。
然后，从该路VC4中解出VC12信号。
由于网元M接收的VC12是从接收的VC4信号流中解出的，所以解出的VC12的时钟特性与接收的VC4的时钟特性一致。
此时，若网元M和网元1的时钟不一致，同样将导致网元M从STM-N信号流中解出的VC12的速率与其处理此VC12的速率不一致。
对于这种不一致，则需要通过TU-PTR指针的调整来进行适配了。
这个操作过程是：
网元M先从接收的SDH信号流中终结段开销和AU-PTR指针，解出VC4（恢复VC4原来的速率）；再从VC4中解出承载2M业务的VC12（速率也为原来的速率）；再通过TU-PTR指针调整适配此VC12的速率；再通过设备的交叉板将此VC12送到支路板上；最后，在支路板上将此VC12中承载的2M业务解出、落地。
在这个过程中，若网元M和网元1的时钟不一致，在将AU-PTR指针终结后，随之将导致TU-PTR的调整。
实际上，如果网元M不是终结站点，是会产生AU-PTR调整，并在转发时将调整后的AU-PTR写入SDH帧中的，所以可以认为AU-PTR的正/负调整，在此操作过程中转化成了TU-PTR的正/负调整。
此时，相应的TU-PTR的值将变化。
由于2M业务在本站落地而不是转发出去，因此设备将仅仅上报给网管本站出现TU-PTR的调整事件，而不会将TU-PTR指针调整后的值转发出去。
这里上报的TU-PTR调整事件，仅仅是对AU-PTR调整转化为TU-PTR调整的一个反映。
示意图见图3。
图3
上面讲述了中间网元以VC4的方式进行业务穿通的情况，当SDH设备以VC12的方式进行穿通时，见图4。
图4
图4中，业务信号在中间站点是通过VC12的方式穿通的，这就意味着每一个中间网元要对接收到的STM-N信号流中的VC4信号进行收端的拆分和发端的重新合成，因为VC12信号是装载在VC4信号中的。
由于中间网元的发端需重新生成VC4帧，所以发端写入的该VC4的AU-PTR指针值恒定为初始值522。
因为各个网元发出的SDH信号流中，该路VC4的AU-PTR的指针值恒定为522，所以，各个网元的接收端均检测不到AU-PTR调整事件，各网元也不会进行针对该路VC4的AU-PTR指针调整。
这种将VC4重新组帧的操作也称之为对VC4的重定帧，即将输出SDH信号流中VC4的位置重新设定为522。
但是对于VC12而言，则需要在中间网元对其进行速率适配（TU-PTR调整），以适配可能出现的SDH网元间的时钟差异。
TU-PTR的调整实现方式类似于AU-PTR的调整方式。
注意：
中间网元进行TU-PTR指针调整时，并不一定会上报TU-PTR指针调整事件。
TU-PTR的指针调整事件的上报点，不同的设备厂家是不同的，但是多数厂家是在业务终结站点处上报的。
与AU-PTR类似，上报指针调整的站点，并不一定是出现时钟不一致的站点，往往是由于上游站点进行了调整，本端站检测了出来。
3．典型案例分析
从上面分析可知，一般来说，导致指针调整的本质原因是SDH设备间出现时钟的不一致，而导致时钟不同步的常见原因有：
Ø时钟源或时钟源级别配置错误，导致出现同一个网中有两个时钟源或两个网元时钟互跟的情况，引起指针调整；
Ø光纤接反，导致出现两个网元间时钟互跟的情况，引起指针调整；
Ø线路板故障导致提起的时钟质量不好，或时钟板故障导致提供的时钟源质量不好、或无法锁定跟踪的时钟源，或长期运行后时钟板、光板损耗过大引起指针调整；
Ø交叉板故障导致其分配的时钟质量不好，引起指针调整；
Ø如果时钟处于失锁状态，应检查时钟是否发生倒换，如果没有发生倒换，可能是由于光板、时钟板故障或长期运行的损耗造成，应更换相应板件。
Ø如果时钟发生了倒换，应检查时钟源配置是否有误，尤其注意数据配置、时钟源等级配置、抽时钟源配置以及时钟倒换规则设置是否正确。
Ø如果时钟源配置无误，应检查倒换后的时钟源是否存在硬件故障，如果存在应更换相应硬件单板。
Ø如果外时钟处于失锁状态，也可按照步骤1～3寻找故障点并解决。
Ø如果是时钟锁定质量不高造成的指针调整事件，可能是光板、时钟板故障或长期运行的损耗造成，应更换相应板件。
Ø支路板故障引起支路指针调整。
由于SDH网络各网元在正常情况下，均同步于某个时钟网关网元的基准时钟（如BITS）。
这时，网上应该没有或仅有少量的指针调整事件——24小时小于50个。
若SDH网络上出现了大量的指针调整性能事件，则反应出SDH网络上的某个站点的时钟与网络基准时钟出现了不一致。
由于指针调整事件具有传递性和隐蔽性，因此需通过指针调整机理对其仔细进行分析，以找到网上时钟失配的站点，进行故障排除。
查找故障需遵循一个原则：
从业务源站点沿信号传输的方向依次查找，直到查找出有时钟失配的站点为止。
查找过程中要关注网络的时钟跟踪方向。
3.1故障分析基础
一般情况下，对于AU-PTR调整而言，设备接收端的群路板进行AU-PTR指针值的检测，若发现前后接收的不一致则上报网管本站发现AU-PTR指针调整事件。
同时收端群路板对VC4进行速率适配，若在适配的过程中进行了AU指针的正/负调整（插入/取出3xH3字节），则在本端设备的发端群路板上（转发群路板上），将AU-PTR改写为新值，附在STM-N信号流中转发下去。
这时，下游站点的收端群路板将检测到AU-PTR指针值的变化，并上报AU-PTR的指针调整事件（图5）。
假设网元3、网元4、网元5、网元6的西向群路板上报大量的AU-PTR指针调整事件，网元6的2M支路板上检测上报大量的TU-PTR指针调整事件。
这时，可以断定网上某个网元的时钟与网络基准时钟出现了较大的不一致，即出现劣化。
我们从业务源站点沿信号流传输方向查找到第一个上报AU-PTR指针调整的站点网元3，依据AU-PTR调整机制获知：
AU-PTR的调整是发生在网元2的西向群路板上，由网元2的东向群路板将调整后的指针值写入SDH信号流，向下游传递，由网元3的西向群路板检测出来并上报网管。
因此，时钟劣化发生在[网元1—网元2]这一段。
具体原因可能是：
网元2和网元1分别跟踪两个时钟基准、网元2设备原因无法跟踪网元1发来的时钟、网元1设备故障导致发给网元2的SDH信号流中的时钟质量太差使SDH无法正常跟踪等。
判断AU-PTR指针调整故障点的一个简便方法：
从业务源站点沿业务流传输方向上的第一个出现AU-PTR指针调整事件的前一个站点，往往就是时钟失步的站点。
由于，网元3东向群路板重写的AU-PTR指针值将沿信号流方向往下游站点转发，网元4、网元5、网元6的接收群路板（W向群路板）均将上报AU-PTR指针调整性能事件，这就是AU-PTR指针调整事件的传递性。
（但要注意，对于少量的AU指针调整，若在下游站以VC4级别穿通，则可能被下游站点的FIFO吸收掉，导致下游站点虽然检测、上报了指针调整事件，但不一定会改写AU-PTR值到发送端的SDH信号中传递给它的下游网元，导致此下游的下游网元不会再上报AU-PTR指针调整事件）网元6的2M支路板上报的TU-PTR指针调整事件则是由网元6的AU-PTR调整事件转化来的，一般不需要单独进行分析。
网元2由于西向群路板接收的AU-PTR指针值恒定为522，所以不会上报AU-PTR的指针调整事件（为什么是这样，大家想一想？
）。
注意：
只有在业务流以VC4的方式进行穿通时（见图5），设备才有可能上报AU-PTR指针调整事件。
对于TU-PTR而言，一般情况下在设备低阶交叉板的信号输入端进行TU-PTR的调整，在低阶交叉板的信号输出端进行TU-PTR的改写，然后附在SDH信号流中传递下去。
而TU-PTR指针调整事件的检测上报点则是在业务的终结站点，由下业务的支路板进行上报。
中间的网元一般不进行TU-PTR指针调整性能事件的上报。
这就是TU-PTR指针调整的隐蔽性（图6）。
图6
假设网元6在2M支路板下2M业务时，监测到该业务通道有大量的TU-PTR调整事件上报。
这时，由于信号是以VC12穿通的，所以各网元的接收群路板（W向群路板）接收的AU-PTR指针值恒定为522（因为各网元的发端均将VC4进行了重新组帧——重定帧操作），所以设备均不会上报AU-PTR指针调整事件。
依据TU-PTR的检测上报机制，我们不能简单的认为时钟劣化站点就是网元6，因为网元6上报的TU-PTR调整事件，很可能是沿业务流传输方向上的某一站点发生了TU-PTR调整，而仅仅在网元6的支路板上被检测上报的。
具体是哪个站点，则可通过如下方法进行判断。
从业务源站点沿业务流方向，利用网上的空闲通道，依次给下游站点配置一个落地业务（图7）。
图7
这时，从业务源站点沿业务流方向上的第一个上报TU-PTR指针调整事件的站点，往往就是时钟的劣化站点。
注意和AU-PTR调整的结论相区别。
SDH设备AU-PTR、TU-PTR的检测上报点和指针值的改写点，不同厂家的设备可能存在不同，但一般情况下与上面所讲的方式类似。
3.2具体案例
导致SDH网络上某个站点时钟劣化的故障分为：
软故障和硬故障两类。
所谓软故障是指设备并没有损坏，而是多由于时钟跟踪方式设置不正确，或因为网络链路故障导致的时钟丢失所引起的某个网元时钟与网络基准时钟不一致。
所谓硬故障是指由于设备相关板件的损坏，例如：
群路板无法正常提取线路时钟、时钟板无法正常锁定线路时钟等硬件故障导致的某个网元的时钟劣化。
不管是软故障还是硬故障，均通过网上的指针调整事件反映出来。
我们只需依据指针调整机理，判定出时钟失配的站点，然后再进行针对性的排障。
下面看两个实际的例子。
3.2.1案例一
图8
在图8中，网元1、网元2、网元3处于汇聚层上，网元1为业务汇聚点，所带环上所有网元的业务都要在此点汇聚。
某天突然发现环上网元（网元4、5、6、7、8）所下的2M业务均出现大量的TU-PTR指针调整事件上报，但监测不到AU-PTR指针调整事件上报。
网元3对接网元2方向的光板检测到大量的AU-PTR指针调整事件上报，网元1和网元2无任何指针调整事件上报。
同时，网元4、5、6、7、8的2M业务出现误码。
根据这些现象，初步断定是该2M业务在传输过程中出现了滑动误码现象。
导致滑动误码的原因可能是信号流在传输路径上的某一站点出现时钟劣化。
因为，环上沿业务流传输方向路径上的第一个出现TU-PTR调整事件的站点为网元4，所以刚开始怀疑是网元4出现了时钟劣化。
但经过反复排查，发现网元4的时钟并没出现劣化。
这时，注意到网元3接收的网元2传来的SDH信号有大量的AU-PTR指针调整事件上报，而网元2并没上报AU-PTR指针调整事件。
经过AU-PTR调整机制分析得知，这是因为网元2是业务源站点（网元1）的相邻下游网元。
由于网元1对承载2M信号流的VC4要进行重定帧操作——将AU-PTR的值初始化为522，就算网元1和网元2的时钟不一致，网元2接收群路板也不会上报AU-PTR指针调整事件（因为其接收的AU-PTR恒定为522），而仅仅对
升级会员 