Turbo boost is responsible for an enormous amount of crappy, slow, complex, and incorrectly defended (by the person who wrote it and “benchmarked” it) code. It’s usually great for general purpose computing, but because it quickly shifts the frequency that your cores are running at, if you run a benchmark for a few seconds without disabling it, it will often give you better numbers for slower code. Disabling turbo boost is one it the most important things to do for quickly measuring performance impact of some patch.
Controlling for frequency should be step 1 for anyone considering whether to make their code less readable for some imagined performance gain. Usually, you’re wrong, but turbo boost or a power saving frequency governor will shift the frequency and make your mistake seem justifiable. It’s a trap that pretty much everyone has fallen for.
Turbo boost is responsible for an enormous amount of crappy, slow, complex, and incorrectly defended (by the person who wrote it and “benchmarked” it) code. It’s usually great for general purpose computing, but because it quickly shifts the frequency that your cores are running at, if you run a benchmark for a few seconds without disabling it, it will often give you better numbers for slower code. Disabling turbo boost is one it the most important things to do for quickly measuring performance impact of some patch.
Controlling for frequency should be step 1 for anyone considering whether to make their code less readable for some imagined performance gain. Usually, you’re wrong, but turbo boost or a power saving frequency governor will shift the frequency and make your mistake seem justifiable. It’s a trap that pretty much everyone has fallen for.
Do note that just using linux-rt achieves much better results than following this guide with mainline.
None of these tweaks stop xruns on jackd at 8ms. Just using linux-rt makes jackd reliable at 2ms.
Cyclictest from rt-test is a better tool than hiccups, for testing scheduling latency.