不是说靠这个办法达到真正的实时。是说如果要求不严格，可以用这个简单办法。

问题是，这种办法大概能达到什么程度？不知道有人用过没有，或者大概范围。
【 在 lvsoft 的大作中提到: 】
: 跟调度没关系，这个是linux内核+x86系统的双重复杂性因素导致的。
: 如果只是内核态独立一个核心出来就能解决问题，那你觉得rt kernel还有啥价值嘛。
: 所以说了，直接上rt kernel。rt不是这么简单的东西，至少里面很多坑都已经被人踩过了。
: ...................
--
FROM 121.69.86.*

能否大致估算一下，那种疯狂轮询的方法能不能达到1ms的要求？
【 在 lipp 的大作中提到: 】
: CPU是1.6G的CortexA8时，运行裁剪后的近实时的Linux时，Jitter-timer可以到10微秒左右，循环周期可以到0.1微秒。
--
FROM 121.69.86.*

用epoll注册个高精timer,把自身优先级提到实时大约50左右，系统不要执行切换tty操作，可以试一下

【 在 wjhtingerx 的大作中提到: 】
:
: rt
:

#发自zSMTH@HMA-AL00
--
FROM 123.122.162.*

不知道，x86 rt的问题坑太深了，cache miss, interrupt这些只能说对于mcu这种很简单的还可以讨论下。
比如我记得比较典型的cortex m3，就说stm32f1吧。靠interrupt极限能达到200ns量级的max jitter。
x86方面intel有篇white paper，我记得丫用了一堆奇淫技巧实现了2us的max jitter，我反正是复现不出来。。。
我尝试过的极限就是4us，还不能维持很久，只能维持10分钟左右...

x86的干扰因素太多了，我当初要折腾的侧重点是实时IO能力。还有pcie总线竞争，cpu动态频率，以及各种奇奇怪怪的驱动。忙等待也是很多驱动在高负载下的常见实现策略。

总的来说就一句话，x86这个系统，从硬件到软件都是为了最大化吞吐量，而不是为了最小化延迟设计的。丫跟本就不适合干这个...就算你在x86上真的折腾出了2us的max jitter，那也一定伴随着大量的BIOS选项调节，大量的内核模块裁减。你的方案大概率会跟一堆确定的品牌主板型号外设特定内核版本绑定，然后过个几年只能去淘旧货才能复现之前的性能...

我现在是完全不折腾这个事情了，加颗MCU简单快速高效可靠的解决高实时性需求不香么...

【 在 moudy 的大作中提到: 】
: x86 cache miss，managemetn interrupt这些能吃掉多少时间？
--
FROM 180.111.50.*

即使 某个线程 或 进程 能够非常精准的  准时触发

操作系统也不保证能立刻调度起响应程序吧 ？

【 在 chunhui 的大作中提到: 】
: 孤立核心为啥不行？是被执行那个过程会被调度？
: 不是放内核里，我是说实时内核。也做不到？
--
FROM 47.144.172.*