调度精度和系统能达到的计时/定时器精度是两码时，调度是根据本地时钟，设置固定间隔的定时实现的，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.*

收藏了。以后遇到要求不高的地方，打算用这个办法。然后按照你说的这几个点弄一弄。
【 在 lambdago 的大作中提到: 】
: 绝大部分时候是可以的
: busy polling 有个问题
: 1 如果你的进程不是实时RT的，那总会有一个默认50us的时间差
: ...................
--
FROM 121.69.86.*

redhat7.6的系统时间就不准。

【 在 lambdago 的大作中提到: 】
: 标  题: Re: Linux应用需要精度1毫秒的定时器，有什么方案？
: 发信站: 水木社区 (Fri Aug 19 09:43:42 2022), 站内
:
: 老黄历了，现在都有hrtimer，计时本身现在已经很准了，rdtsc 了解下，
:
: 问题在于用户通过系统调用带来的抖动太大了，任务调度和中断等等。
:
: 【 在 liuxueshen 的大作中提到: 】
: : 没用，linux本身计时器有误差，加上系统本身不是实时的，1ms基本不可能。
: : 否则用gettimeofday就行，里面有微秒。
: :
:
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 111.181.47.*]
--
FROM 112.132.251.*

你意思频算时有问题？那上面说的精确定时是个什么方式？

【 在 JulyClyde 的大作中提到: 】
: 标  题: Re: Linux应用需要精度1毫秒的定时器，有什么方案？
: 发信站: 水木社区 (Fri Aug 19 14:51:10 2022), 站内
:
: 时频虽然是个词组，但时和频其实是两码事
: 【 在 liuxueshen 的大作中提到: 】
: : redhat7.6的系统时间就不准。
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 222.71.112.*]
--
FROM 112.132.251.*