I am using a video encoding benchmarking application. The strange thing to me is that when I am using the command sudo chrt -r 99 VideoEncoding cfg I always get bigger time (worse results) instead of using just VideoEncoding cfg. The difference between them is about 200 seconds for 150 frames which is huge. It is supposed that changing the real-time attributes of a process it will be faster, but instead, it proved to be slower.

Can someone explain this?

PS : I am running the benchmarks under Ubuntu 20.04 LTS

  • 1
    This is a total misunderstanding of what real time semantics guarantee: you're always trading off latency, throughput, and the risk of priority inversions.
    – Chris Down
    Aug 21, 2022 at 18:27
  • @ChrisDown Can you explain more on this? Smaller latencies better results, can RT properties achieve this? What about throughput and priority which as far as I remember is set to Round Robin?
    – Maverick
    Aug 23, 2022 at 10:49

2 Answers 2


It is supposed that changing the real-time attributes of a process it will be faster

This is definitely wrong.
Scheduling whatever under a real time policy might help achieving precise & deterministic latency, sync between tasks… but since there is no free lunch to the expense of throughput.

In the particular case of whatever cpu-bound task (what a video encoding task is) what you want is : throughput !

Therefore… scheduling that sort of task SCHED_RR will only kill the performances of everything on your system (this including… your benchmarking application).
And the more your cpu-bound task is multithreaded (likely with modern cpu-bound tasks), the more degraded perfs you will observe.

Renicing it should be just far enough to achieve better performances or, at the extreme limit, if highest possible performance needed then pin this task on some idle cpu.

AND, BTW : Never never and never schedule anything RT with the max possible priority. If anything goes wrong, you'll never be able to do anything else but a hardware reset.

Not to say BTW 2 : Benchmarking whatever RT system with whatever benchmarking application running under that same system is just : absurd.

  • Thanks for the comment. So the SCHED_RR will kill performances., right? The conclusion here is to avoid using chrt ? What else can I do to get stable performances for all my benchmarks? I used also to change the scaling_governor to performance like this echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor. Do you suggest anything else?
    – Maverick
    Aug 22, 2022 at 8:05
  • It doesn't "kill performance": it reduces throughput, but if your performance is measured in worst-case response time, it rescues performance. You need to think about how your transcoding system might have different notions of performance compared to an audio subsystem that needs to guarantee sound getting to and from applications in time, or a CNC control system that needs to emergency shutdown within 2 ms if something happens, or a cellular base station which needs to have responded to a control packet within 4ms, including generation of the RF signal. Aug 22, 2022 at 8:27
  • (also, if there was one golden way to make your computer faster without downsides, then any serious operating system would do that, by default!) Aug 22, 2022 at 8:28
  • @Maverick : When benchmarking whatever, do realize that A/ because initial conditions cannot be identical, benchmarks (even without changing anything in whatever configuration) will necessarily provide two different results. So you must always run your benchmark several time and consider the standard deviation. B/ because whatever benchmark (running on the same machine) will have to run at some time, it will pollute the result. => best is to get rid of the benchmark app and read the data you are interested in at a given moment of your workload and re-read that data at another moment.
    – MC68020
    Aug 22, 2022 at 16:22
  • @MC68020 I can not run my benchmark several times since they are very time-consuming and too many, consequently, I need weeks to finish only the 1st run. Since they are very time critical and they are using multithreading CPUs and GPUs, I want to benchmark minor updates to the source code and watch the final improvements. The problem here is that if I can not get reliable results to monitor the minor speedups then there is no way to improve the code. Under Windows which is the main developing system I can monitor the speedups but under Linux the whole project is falling down because of this.
    – Maverick
    Aug 22, 2022 at 18:09

is supposed that changing the real-time attributes of a process it will be faster,

No. That's not true!

Making a process "real-time scheduled" doesn't make it faster, it just guarantees a maximum time between the process being scheduled. That leads to potentially more context switches, and hence effectively makes the system slower.

  • I am not sure… hmmm… I'm quite certain :-P that there should be no noticeable increase in context switches (because of task trheaded RR) an even less that context switches would, per se, be responsible for eating 200/150 seconds cpu per frame processing.
    – MC68020
    Aug 21, 2022 at 16:18
  • But there should be. In non-rt processing, your encoding process runs until it context switches, or until an interrupt interrupts. On a multicore machine, that might simply mean the encoding process gets a full CPU core (or even multiple) for a looong time. RT scheduling is period-based, you're getting invoked at the end of each period (e.g., 10ms), but the OS rightfully assumes you're not going to work the whole period (otherwise, your real-time-ness makes no sense), so you get grouped on a CPU core with other short-running tasks. Aug 22, 2022 at 5:25
  • What can I do to have a stable performance for my benchmarks? I used to change also the scaling_governor to performance.
    – Maverick
    Aug 22, 2022 at 8:06
  • 1
    if you want to say something like "95% of times I'm within 5% of the mean value", you will have to do a lot more than 3 runs. This is a statistics problem. Aug 22, 2022 at 19:24
  • 1
    @MarcusMüller : For once on this one I wholeheartedly second you ! I think that OPs problem is more about benchmarking in general than about RT scheduling per se. (About what, between you & me… I will… keep standing on my position ! :-P ) ;-)
    – MC68020
    Aug 22, 2022 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.