Messages in this thread | | | Date | Sun, 4 Nov 2012 17:03:58 +0000 | Subject | Re: The uncatchable jitter, or may the scheduler wars be over? | From | Lukasz Sokol <> |
| |
A word of addition,
On Sun, Nov 4, 2012 at 2:04 PM, Uwaysi Bin Kareem <uwaysi.bin.kareem@paradoxuncreated.com> wrote: [snip] > > Also like I stated elsewhere, since daemons seem to make a difference, > optimally putting daemons or processes that can, on a low-jitter queue, > transparent to the user, seems optimal. Unfortunately realtime is not quite > working as one would expect, causing input to be choked at times, if you > want to have one main app, and the rest on sched_other, as a low-jitter > queue. So I am still iterating this.
Hard real time kernel, will make the situation even worse: there the userspace will get preempted always and no matter what it is doing; RT means here, the userspace will /get/ the slice, but whether the slice will be enough, no one can guarantee but whoever wrote the userspace. It's the userspace that must decide 'do I have enough time to run another rendering loop within this time slice (or before vsync is imminent)'.
(As in: real time is not 'as fast as possible' but 'as fast as specified' and the specification need to be within reason).
> [snip] > Peace Be With You.
Lukasz
| |