然而我们看到，目前各省的数据跳变统计表明，实际系统的跳变持续时间大大超出了上述区间，原因是：
1、对跳变的机制、原因还没有进行深入的研究；
2、没有采取措施，改善系统的通信设置。
三、遥测数据发生跳变的原因
EMS主站对厂站设备的大多数采集命令，都有一旦执行不可中断的性质。以全数据请求（简称：总召）为例，对一个具有几千个数据点的RTU的全部数据采集一遍，往往需要几十帧报文，花费几十秒钟时间，具体视信道带宽的不同而有不同。
在全数据采集过程中，当RTU某个刚刚被采集过的数据内存的数据发生变化时，这种变化不能立即被送往主站，必须等到本轮全数据请求全部完成后，在接下来的变化数据请求中被送往主站。
如果这个站的全数据采集需时40秒，在它刚刚采集到10秒钟的时候，刚才10秒内已被采集过的某个数据内存的数据发生变化，那么这个变化了的数据，起码要在30秒钟以后，才能被送往主站。
我们当然可以在规约的编程上来改变这个总召不可中断的局面，比如，在10秒时中断总召命令，先传送上面所说这个刚变化了的数据，这是能够做到的。但请注意，我们为什么要发全数据请求命令？因为在经过了很长一段时间的变化数据请求以后，主站数据库中这一块数据是否还与厂站保持一致？我们是有疑问的，很多数据在12个小时内都没有被刷新一次，在他们被主站的各种应用程序几十次地读取、比对、处理中，会不会出错？为了保险，这个时候，妥当的做法是把这个站的数据全部刷新一遍，以确信，这时候主站数据与厂站实际状态是一致的，如果不这样做，很可能更多的面上的错误会发生在这个厂站的数据中。所以，每隔一段时间对一个站的整个数据刷新一遍，也是很重要的，不可偏废。再说，在调度可以接受的限度内，这个变化了的数据稍微延后一点送上去，又有何妨？比较利弊得失，还是不中断的好。
现在再来探讨这个延迟上送的变化了的数据带来的问题。
如果这个数据变化不大，虽然已经越过了死区，必得上送，也只是平稳负荷曲线上的一个小小的波动，虽然延迟了30秒才到达主站的数据库，但在当前一轮的汇总计算中，基本上显示不出什么来。事实上，对于平稳的负荷，你一小时上送一次也没有什么问题。