Ryzen 9 Support
entropie
Status: New User - Welcome
Joined: 31 Jul 2019
Posts: 1
Reply Quote
Hey there,

first of all thanks for the great liquorix kernel, I am using it for a couple of months now and I am pretty happy with it.
Now my question: I just updated to a Ryzen 9 3900X and its running perfect on the latest kernel. Yet those R9s still have issues to reach their max advertized boost clock, which is prolly related to their BIOS Agesa versions still needing optimisations. I am currently looking into that matter and want to learn more about it and was wondering, if there are Zen2 specific optimisations in the liquorix kernel or if there are any options I can try out.

I have made some single core benchmarks, where I let a Fast Fourier Transformation run contained to every of the 24 logical cores and the result is:

Highest I get is 4,44 Ghz on Core 13, I tested all of them:
https://openbenchmarking.org/result/1907307-HV-SINGLECOR71

On Core 0 the average fps are highest with 4,23 Ghz:
https://openbenchmarking.org/result/1907306-HV-DSFDS326725

Obviously the Ryzen architecture has different clock speeds on their cores, Core 0 and 13 are the two logical ones, which are the physical Core 0. At 4,44 ghz I am almost at 4,6 Ghz but not quite there yet.

Since I barely now stuff about the workings of liquorix just tell me if my question is nonsense or if you have any ideas and hints on this, I'ld like to know. I havent tweaked anything in the BIOS yet, just running on stock, only the RAM is at 3200 Mhz.

Thank you for your time,
Greetings ~ent
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 757
Reply Quote
Hi entropie,

In general, it'll be more difficult for you to hit the peak max boost clock on your CPU that's only attainable on single cores. This is because MuQSS more aggressively utilizes idle cores even when a single task is running, so it'll bounce between cores that share cache quite often. Task bouncing isn't particularly a problem unique to MuQSS, but the mainline scheduler CFS is better at pinning single threaded busy tasks to the same core it was running, so you should get a higher score if you stick with your distribution's stock kernel.

However, don't confuse benchmark scores with responsiveness. Liquorix typically scores worse in most synthetic benchmarks due to its higher context switching rate and usage of MuQSS. The trade-off is a system that feels better and more responsive for workstation type usage where you have lots of things running. I understand that's not what we're measuring here so lets move on to the actual boosting capabilities of the new Ryzen CPUs.

Toms Hardware released an article[1] discussing turbo boosting on Ryzen 3000 and found that not all cores are equal. In fact, the updated driver in Windows 10 is designed to understand which cores are the fastest and use those for single thread boosting whenever possible. As of now, both MuQSS and CFS understand general CPU topology by cache distance, but not by core quality. There's other efforts from Qualcomm to understand big.LITTLE architectures that are already used on android phones, which is similar but not the same.

And the only work I'm aware of to aggressively take advantage of single core turbo speeds are patches[2] developed by IBM to pack unimportant jitter tasks on to already active cores. But it's pretty clear from reading the abstract (to me at least), that this would be horrible for interactive usage like processing mouse cursor movements, desktop compositing, Xorg responding to input. All those things you want to respond as fast as possible, so running them all in parallel to get their time slice executed as soon as possible is more desirable, rather than as fast as possible but late.

[1] www.tomshardware.com/reviews/amd-ryzen-3000-turbo-boost-frequency-analysis,6253.html - Our Tests Show Not All Ryzen 3000 Cores Are Created Equal
[2] lkml.org/lkml/2019/7/25/296 - [RFC v4 0/8] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations
Back to top
Display posts from previous:   

All times are GMT - 8 Hours