- 主题:Linux应用需要精度1毫秒的定时器，有什么方案？
看你要的精度如何，一般来说，精度由高到底：
busy polling > nanosleep > settimer 定时器
【 在 wjhtingerx 的大作中提到: 】
: rt
--
FROM 111.181.47.*
老黄历了，现在都有hrtimer，计时本身现在已经很准了，rdtsc 了解下，
问题在于用户通过系统调用带来的抖动太大了，任务调度和中断等等。
【 在 liuxueshen 的大作中提到: 】
: 没用，linux本身计时器有误差，加上系统本身不是实时的，1ms基本不可能。
: 否则用gettimeofday就行，里面有微秒。
:
--
FROM 111.181.47.*
调度精度和系统能达到的计时/定时器精度是两码时，调度是根据本地时钟，设置固定间隔的定时实现的，100HZ-1000HZ，根据内核配置。
定时器是通过重新编程本地时钟定时器实现的，类似于在100HZ外重新tick一下，硬件的定时精度很高了，之所有很抖动是中断，上层任务调度等导致的。
【 在 RunningOn 的大作中提到: 】
: Linux的任务调度的时间精度是在10ms左右，要1ms的精度通常是不可能的。
: 如果要用Linux做实时任务，一般的做法是：
: 1. 独立出一些CPU核，这要修改grub启动参数。这些被独立出的核一般的进程不能使用。
: ...................
--
FROM 111.181.47.*
绝大部分时候是可以的
busy polling 有个问题
1 如果你的进程不是实时RT的，那总会有一个默认50us的时间差
2 如果你的进程不是实时RT最高优先级的（RT99），那可能会被调度出CPU；
3 即使你的进程是实时最高优先级的，进程还是可能被调度出CPU，因为/proc/sys/kernel/sched_rt_period_us 保证你只能用到95% 的CPU时间；
4 即使你的进程是实时最高优先级的，/proc/sys/kernel/sched_rt_period_us 也设置为100%，你会发现你的进程还是被系统中断了（LOC中断，TLB中断）；
5 即使你的进程是实时最高优先级的，/proc/sys/kernel/sched_rt_period_us 也设置为100%，还想办法屏蔽了中断，你会发现你的进程还是不断的被NMI中断；
6 即使你的进程是实时最高优先级的，/proc/sys/kernel/sched_rt_period_us 也设置为100%，还想办法屏蔽了中断，关闭了NMI watchdog，你发现进程还是有抖动，来自于操作系统以下的硬件问题；
并且在你屏蔽某个核心的中断过程中，你机器宕机了，因为其他核心发起的IPI中断被你的busy polling阻塞而导致整个机器无法响应了。
【 在 chunhui 的大作中提到: 】
: 能否大致估算一下，那种疯狂轮询的方法能不能达到1ms的要求？
--
FROM 111.181.47.*
影响大啊，建议你用nanosleep，
但问题是这是通过系统调用实现的，会有额外的开销，且在负载较重的时候抖动更大。
【 在 wjhtingerx 的大作中提到: 】
: polling这种，对性能影响大吗？
: :
--
FROM 111.181.47.*