[shlug]Linux schedule latency

[david pu]

以前都在吐槽Linux实时性不好，不过现在看来在Android上已经可以保证+/- 1ms的schedule
jitter已经不是不可能了，Android L的fast mixer就有这个硬性的要求。

--
() ASCII Ribbon Campaign
/\ Keep it simple!

[Grissiom]

2014-12-15 10:40 GMT+08:00 david pu <pulq...@gmail.com>:

以前都在吐槽Linux实时性不好，不过现在看来在Android上已经可以保证+/- 1ms的schedule
jitter已经不是不可能了，Android L的fast mixer就有这个硬性的要求。

schedule jitter 只是实时性的一个方面。真正的实时系统主要关注的是系统中的确定性，尤其是中断延迟。这方面 Linux 差的还很远～

--

Cheers,
Grissiom

[Wales Wang]

Linux kernel这些年做了很多real time的工作。

mainline kernel合并后主要达到了Soft real time的要求。

另外的patch可以达到hard real time，patch是PREMPT-RT

确定性保证，latency是微秒级别的。

Wales Wang

--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
---
您收到此邮件是因为您订阅了Google网上论坛上的“Shanghai Linux User Group”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到shlug+un...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Wales Wang]

PREMPT-RT patch剩下的hard real time功能没有合并进mainline，是因为hard real time有副作用，影响了CPU的工作效率。

需要hard real time就自己加该patch。或者买包含它的Linux 发布的服务，如MVista Linux

Wales Wang

[Grissiom]

PREEMPT-RT 打上去中断延迟在 ARM 上也是在几十到百微妙的级别，可以满足一些场景，但是很多场景还是满足不了的。

数据来源：

https://www.osadl.org/Individual-system-data.qa-farm-data.0.html

Cheers,
Grissiom

[Wales Wang]

那就看看RT-Thread吧。1微秒latency。

加上它的bigLITTLE OS方案，满足各种应用。

Wales Wang

[Wales Wang]

SeL4微内核OS加RT 的L4Linux的方案也有人用。

Wales Wang

[david pu]

RT 和throughput之间本来就是矛盾的呵呵。
在例如Android这样的平台上面，实时性主要是为了获得更好的用户体验，特别是降低Audio output latency.

2014-12-15 12:57 GMT+08:00 'Wales Wang' via Shanghai Linux User Group
<sh...@googlegroups.com>:

[liyaoshi]

你觉得现在的延时还能忍受？
扯个不相干的，Ti之所以有个pruss,这个真的是5ns一个指令,拉gpio，相比arm,同样的汇编，只干一件活，实际量下来超过200ns
所有的实时系统，其实多有响应延时，就看最后有多关乎人命。

david pu <pulq...@gmail.com>编写：

>您收到此邮件是因为您订阅了 Google 网上论坛的“Shanghai Linux User Group”群组。

[david pu]

这里其实不是讲指令的延时了，是Linux scheduler的延时，或者是CPU timer + Linux scheduler所能保证的jitter返回。
进程调度能控制在+/- 1ms的delay已经满足绝大多数Audio use case了。
一般PC上即使CPU loading很轻的情况下这个值可能在+/- 10几个ms吧.

[Grissiom]

2014-12-15 13:22 GMT+08:00 'Wales Wang' via Shanghai Linux User Group <sh...@googlegroups.com>:

那就看看RT-Thread吧。1微秒latency。

加上它的bigLITTLE OS方案，满足各种应用。

Wales Wang

嘿嘿嘿，看来我们的宣传还是有效果的。我平时是混 RT-Thread 社区的 ;D

--

Cheers,
Grissiom

[david pu]

呵呵，其实不是说这玩意越实时越好，毕竟我是在跑Android :P
需要控制schedule jitter是出于这个的要求：https://source.android.com/devices/audio/latency_design.html

Period

The fast mixer runs periodically, with a recommended period of two to three milliseconds (ms), or slightly higher if needed for scheduling stability. This number was chosen so that, accounting for the complete buffer pipeline, the total latency is on the order of 10 ms. Smaller values are possible but may result in increased power consumption and chance of glitches depending on CPU scheduling predictability. Larger values are possible, up to 20 ms, but result in degraded total latency and so should be avoided.

Scheduling

The fast mixer runs at elevated SCHED_FIFO priority. It needs very little CPU time, but must run often and with low scheduling jitter. Running too late will result in glitches due to underrun. Running too early will result in glitches due to pulling from a fast track before the track has provided data.

--

-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
---
您收到此邮件是因为您订阅了Google网上论坛上的“Shanghai Linux User Group”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到shlug+un...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

[Wales Wang]

熊自己在这说的。这个real time话题其他人在这问过。

Wales Wang

--