The time 'round triip' is purely hardware dependent, it has almost no meaning as an absolute, depends on ram, ram speed, cpu, core counts, etc.

I'd resist the urge to overthink this, and focus more on actual machines and software. Just citing a desired latency i milliseconds without specifying the target hardware makes it a meaningless goal.

Once you start defining real empirical things, and the kernel configurations that result in various behaviors, you may start to get somewhere, but it's unlikely you will before that.

I don't deal with the guts of schedulers or the kernel configurations ever, not my thing, but I know enough to know that everything you tweak or change will impact other things in either desirable or undesirable ways, and no tweaks will be better in all ways, in other words, it's always a balance and a compromise.

Also consider what the developers do, lol, for example, if damentz games, well then he will want Liquorix to work well when gaming on gnu/linux. On his system. If I want to do heavy audio processing, then I want it to be reliable for that, which it is. That's not live audio recording however, it's just working with large amounts of audio data.

As noted, if I were into it, I'd boot into Debian vanilla kernel and see if I could notice any difference in desktop performance under various workloads, but I'm not really into that type of a/b testing, it's very hard to reproduce the same exact loads on the ram, cpu, machine overall, moment to moment.

I avoid overthinking it, and ask, have I noticed anything annoying with the kernels? if not, then they are probably fine, if so, then I report the issue to damentz who will generally know what happened [testing something new, a new scheduler, etc].

But this to have meaning has to come down to a level of actual software running on real hardware, not arbitrary performance targets that don't mean anything out of context of hardware and workload on system at that moment.

I've slowed my system to a crawl many times by maxing it all out, and it slowed not because it was liquorix kernel, it slowed because the hardware resources were totally maxed out, all cores occupied doing hard work, for instance...
Back to top