none
关于精确定时的问题 RRS feed

  • 问题

  • 描述:现有一个项目,需要每隔26毫秒(必须精准)将语音数据(大约600byte),通过UDP方式发送数据到嵌入式设备。因嵌入式设备提供的缓冲区只有10K大小,故要求计算机发送速度不能太快,太快缓冲区溢出;太慢嵌入式设备无法获得语音数据用于播放,处于停顿。

    目前处理方法:

    1、采用的是多媒体定时器。采用的26毫秒定时触发一次,但通过网络抓包和程序日志发现定时器,其不能确保在26毫秒就触发了,可能是15.25毫秒也可能是31毫秒或26毫秒触发的,因时间的累积效应,终会导致嵌入式设备缓冲区溢出。也试图模拟缓冲区大小进行速度控制,但发现几乎无法控制正确。程序是多线程的。

    问:

    1、可有精准按时触发的?

    (网络上提供的很多高精度,基本都是单线程和占用极高CPU来实现的,不适合本项目)

    2、求其他解决方案。

    (硬件缓冲区,目前无法调大)

     

    2011年12月21日 3:46

答案

  • 从 Windows 本质来说,Windows 是一个非实时操作系统,其内部时钟的可表示的有效时间间隔是 1/64 秒,也就是 15 毫秒左右。Windows 的 CPU 时间片切换时间间隔大概是 31 毫秒,普通的计时器,包括 System.Threading.Timer, System.Timers.Timer 等,可能都会存在延时/提早的问题,但误差不会高于 1/64 秒。运气不好刚好在该时间间隔内发生 Thread Context 改变的话那就会延迟到 31 毫秒+。这也就是为什么很多高精度方案都是单线程或者 Spin CPU 的方案了。
    Mark Zhou
    2011年12月21日 9:02

全部回复

  • 从 Windows 本质来说,Windows 是一个非实时操作系统,其内部时钟的可表示的有效时间间隔是 1/64 秒,也就是 15 毫秒左右。Windows 的 CPU 时间片切换时间间隔大概是 31 毫秒,普通的计时器,包括 System.Threading.Timer, System.Timers.Timer 等,可能都会存在延时/提早的问题,但误差不会高于 1/64 秒。运气不好刚好在该时间间隔内发生 Thread Context 改变的话那就会延迟到 31 毫秒+。这也就是为什么很多高精度方案都是单线程或者 Spin CPU 的方案了。
    Mark Zhou
    2011年12月21日 9:02
  • 为什么不用流控制呢?

     


    我也有自己的签名档哦!
    2011年12月22日 9:54
  • 流怎么控制?
    2011年12月26日 7:30
  • 你说的单线程高精度方案是什么啊?
    2014年11月24日 8:19