Hah I just wish gears would go away. If I get hardware where it runs at just
the right speed it looks like it doesn't move at all. On other hardware the
wheels go backwards and forwards where the screen refresh rate is just
perfectly a factor of the frames per second (or something like that).
This is not a cpu scheduler test and you're inferring that there are cpu
scheduling artefacts based on an application that has bottlenecks at
different places depending on the hardware combination.
To imply something is fishy with nice levels, do a test that _only_ uses cpu
(and not the bus, memory bandwidth, the gpu and has driver interactions) and
prove that there is something wrong. What happens to other resources on the
machine the cpu scheduler has no control over. The -rt tree tries to address
these factors for example but it's a huge - some would say insurmountable -
thing to try and manage at all levels on a general purpose operating system.
The cpu is proportioned out very fairly with rsdl on both quota and latency
according to nice vs cpu usage. When something is fully cpu bound on rsdl its
average and maximum latency will be greater than something that only
intermittently uses cpu. The (somewhat lengthy and not easily digestible)
docs describe how you can model what these latencies will be.
Thanks!
--
-ck
-
