For the most part, Liquorix should always lose on throughput benchmarks. Most of Phoronix's benchmarks focus on those.
You can check the comments regarding a discovery that certain sched_yield configurations destroy performance on out-of-tree schedulers and was amended post benchmarking.
This however was using MuQSS, which was notorious for poor single thread performance. Liquorix now uses PDS which attempts to use all physical cores before deferring to SMT threads. This completely changes performance for lightly threaded workloads.
There's been no news-worthy benchmarks since Liquorix switched from MuQSS to PDS.
Anecdotal, but I noticed a lot better browser performance when switching to no I/O scheduler, "none". I also noticed that Linux wasn't trying to use most of my RAM for buff/cache.
> Maybe the extra responsiveness under heavy loads is slowing it down?
Probably. It's a basic tradeoff in multitasking. A process can be left in cache and run for hundreds of milliseconds at high efficiency. Or the kernel can constantly juggle contexts in and out quickly, wasting cycles to reduce the delay between time slices and (potentially) allow fast response.
Yes, exactly. Let's imagine you were running two processes on one core, a server and a video game.
The way to achieve the highest /average/ frame rate regardless of latency would be to pause the game for a good second, run the server, pause the server, run the game for a second, and repeat. This has much lower overhead than swapping between them perhaps 100 times a second. Except it's super laggy. Swap them out 100 times a second and the process only has to wait maybe 10 ms until it next executes and appears much less laggy, but total throughput decreases.
> Maybe the extra responsiveness under heavy loads is slowing it down?
Yes! Extra responsiveness is done by switching more often between tasks. This is not free, so throughput suffers. The linux kernel lists that as the downside of e.g. 1000Hz ticks (something the Liquorix kernel enables).
On arch, I definitely get better gaming performance than the stock kernel. The liquorix repo's arch kernel doesn't play well with libvirt - that's about my only gripe.
Xanmod kernel seems to have all the gaming improvements and still plays nice with libvirt though.
>Zen Kernel — Result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems. Some more details can be found on https://liquorix.net (which provides kernel binaries based on Zen for Debian).
Be aware it's normally slower for server-workloads, but more responsive for Desktop-Stuff (Tunes the kernel for responsiveness at the cost of throughput and power usage), but on arch you can install it directly from the official sources (called zen-kernel there):
I find this categorization of server workloads as something that is not latency sensitive bit weird. I'd imagine tons of server workloads that serve interactive users, for example a web server, should also care latency. If you for example are targeting <100ms p99 latency for your web service, then to me that sounds like it'd fall in the same ballpark as desktop use?
Sure there are still some batch workloads or other non-latency sensitive things around, but I'd almost expect those to be in the minority these days for servers.
Why? It's well scoped: "the best ... for desktop, multimedia, and gaming workloads".
The Linux kernel is buit for all sorts of devices, including embedded, servers, desktops, phones, etc - it's not hard to imagine the default settings being not perfectly optimized for a specific usecase (that said, I have not tried the lqx kernel or looked at benchmarks, but the claim doesn't seem outrageous).
There are lots of these with many modern languages, where someone who was familiar with both a foreign language (often a classical or scholarly language) and a local language consciously adapted the vocabulary:
Hi! I know this is completely unrelated, but hackernews has no PM functions, so I'm posting this here. Schoen, you posted a comment on here a couple of years ago looking for an English translation to a book on obfuscated programming. I could not find much info online about getting an English copy and I also really wanted to read it, so I threw a copy into google translate, and its surprisingly readable. Since you are one of the only people I could find online also looking for an English copy, I just wanted to make you aware of its existence. If you don't care about this at all, sorry for bothering you. If you do care, here is a link: https://obfuscationandesotaric.neocities.org/
Have a great day!
Only speaking for me: because absolute superlatives like “the best” suggest some sort of measurement and methodology which isn’t shown, whereas “optimized for”/“purpose built for” usually has at least some demonstration of the claim attached.
A big latency spike in latency and your desktop seems to hang, the audio shutters or you see framerate drop (or even freezes) in games.
How do you go after these? You optimize for fairness (which guarantees your workload a fair fraction of the resources) and frequent scheduling (higher frequency / smaller slices).
The downside is that you will trade in maximum throughput.
Looking at the settings I can see that this is what they adjust, but they should clarify what they regard as crucial for such a setup.
I've been using this on Debian 11 on an HP ML330 G6. It has dual xeons.
The main reason is that there is a bug in the normal Debian kernel that prevents that specific machine from booting with a kernel panic. The bug seems to be fixed in later kernel versions, hence Liquorix.
That machine also boots fine from a debian 10 kernel which is how I was able to install liquorix after the debian 11 upgrade went sideways.
There are newer Linux kernel versions in Debian bullseye-backports btw. Also, if you know which patch fixes the panic, you might want to get it into the Linux kernel LTS releases, which end up in Debian stable after a month or two.
I can confirm that running my Ubuntu 20.04 on a xanmod kernel improved my FPS in Cyberpunk from around 40 to 65-70. And because it's only a kernel, this is the simplest and quickest way to improve your gaming experience.
What is your hardware if I may ask ? 60ms is outrageous - I run the stock kernel and have had no issues with fairly small buffer sized, e.g. 32/48/64 frames (around 1 millisecond) in jack settings
I'd bet money they haven't played with their buffer size, because you're right, 60ms is basically unusable unless you're just mixing. I had a PC 15 years ago with a PCI Layla 8 channel input that got better latency than 60ms.
> I had a PC 15 years ago with a PCI Layla 8 channel input
aha the first soundcard I bought was an ESP 1010... brings back good memories ! it was running on and it was also able to go quite below 60 ms too, I did not have too many issues playing live with guitar amp sims with it, between 8 and 10ms of latency IIRC ? on an athlon xp 3000 or 3200+...
iRig2. It was some time ago, so I can't give you all details for comparison, but I'm pretty sure that was pre-buffer-tweaking. However making the buffer smaller improved both sides so xanmod was still winning. (With the same small buffer xanmod was perfect but stock started getting xruns)
This might be a noob question but does this rebuild the zfs kernel modules as well for those of us using it on LTS? Can we use this on teh LTS version?
46 comments
[ 3.3 ms ] story [ 120 ms ] threadYou can check the comments regarding a discovery that certain sched_yield configurations destroy performance on out-of-tree schedulers and was amended post benchmarking.
This however was using MuQSS, which was notorious for poor single thread performance. Liquorix now uses PDS which attempts to use all physical cores before deferring to SMT threads. This completely changes performance for lightly threaded workloads.
There's been no news-worthy benchmarks since Liquorix switched from MuQSS to PDS.
Maybe the extra responsiveness under heavy loads is slowing it down?
Probably. It's a basic tradeoff in multitasking. A process can be left in cache and run for hundreds of milliseconds at high efficiency. Or the kernel can constantly juggle contexts in and out quickly, wasting cycles to reduce the delay between time slices and (potentially) allow fast response.
The way to achieve the highest /average/ frame rate regardless of latency would be to pause the game for a good second, run the server, pause the server, run the game for a second, and repeat. This has much lower overhead than swapping between them perhaps 100 times a second. Except it's super laggy. Swap them out 100 times a second and the process only has to wait maybe 10 ms until it next executes and appears much less laggy, but total throughput decreases.
Yes! Extra responsiveness is done by switching more often between tasks. This is not free, so throughput suffers. The linux kernel lists that as the downside of e.g. 1000Hz ticks (something the Liquorix kernel enables).
On arch, I definitely get better gaming performance than the stock kernel. The liquorix repo's arch kernel doesn't play well with libvirt - that's about my only gripe.
Xanmod kernel seems to have all the gaming improvements and still plays nice with libvirt though.
(Also run zen on my main gaming rig, another fantastic kernel)
>Zen Interactive Tuning: Tunes the kernel for responsiveness at the cost of throughput and power usage.
https://liquorix.net/#features
>Zen Kernel — Result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems. Some more details can be found on https://liquorix.net (which provides kernel binaries based on Zen for Debian).
https://wiki.archlinux.org/title/kernel
https://wiki.archlinux.org/title/kernel
I find this categorization of server workloads as something that is not latency sensitive bit weird. I'd imagine tons of server workloads that serve interactive users, for example a web server, should also care latency. If you for example are targeting <100ms p99 latency for your web service, then to me that sounds like it'd fall in the same ballpark as desktop use?
Sure there are still some batch workloads or other non-latency sensitive things around, but I'd almost expect those to be in the minority these days for servers.
>If you for example are targeting <100ms p99 latency for your web service.
Ah yes absolutely, if that needs that to be guaranteed maybe even real-time.
Hearing "the best" there really bugs me for some reason.
The Linux kernel is buit for all sorts of devices, including embedded, servers, desktops, phones, etc - it's not hard to imagine the default settings being not perfectly optimized for a specific usecase (that said, I have not tried the lqx kernel or looked at benchmarks, but the claim doesn't seem outrageous).
https://en.wiktionary.org/wiki/optimus#Latin
(But I guess "best" can have a connotation of marketing-speak, while "optimized" can have a connotation of engineering-speak.)
https://en.wikipedia.org/wiki/Calque
It's always fun and satisfying for me to happen upon these. :-)
I will definitely read this.
A big latency spike in latency and your desktop seems to hang, the audio shutters or you see framerate drop (or even freezes) in games.
How do you go after these? You optimize for fairness (which guarantees your workload a fair fraction of the resources) and frequent scheduling (higher frequency / smaller slices).
The downside is that you will trade in maximum throughput.
Looking at the settings I can see that this is what they adjust, but they should clarify what they regard as crucial for such a setup.
The main reason is that there is a bug in the normal Debian kernel that prevents that specific machine from booting with a kernel panic. The bug seems to be fixed in later kernel versions, hence Liquorix.
That machine also boots fine from a debian 10 kernel which is how I was able to install liquorix after the debian 11 upgrade went sideways.
https://www.kernel.org/doc/html/latest/process/stable-kernel...
https://wiki.debian.org/DebianKernel/GitBisect
Tip from it: use the Debian wayback machine to do the first narrowing down:
https://snapshot.debian.org/package/linux/
Not sure how it compares to liquorix, but xanmod allowed me to go from 60ms+ to <10ms in pipewire latency.
Definitely recommend xanmod.
aha the first soundcard I bought was an ESP 1010... brings back good memories ! it was running on and it was also able to go quite below 60 ms too, I did not have too many issues playing live with guitar amp sims with it, between 8 and 10ms of latency IIRC ? on an athlon xp 3000 or 3200+...
The zfs module built just fine.
update: gpu works fine, zfs is not working -- looked like the kernel module was built but I must have been mistaken.
update2: install deps then
sudo make clean && ./configure && make && make deb-dkms && sudo dpkg -i ...
and then import pools as needed