31–40 of 47 posts
If anyone has tried this on arch I'd love to hear your experience... I've got a home server sitting in my living room that looks bored.
If anyone has tried this on arch I'd love to hear your experience... I've got a home server sitting in my living room that looks bored.
I run his kernel on my daily workstation at my day job :3 its stable and fantastic. (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).
> Liquorix is a distro kernel replacement built using the best configuration and kernel sources for desktop, multimedia, and gaming workloads. Hearing "the best" there really bugs me for some reason.
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.
Earlier quoted context omitted.
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.
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+...
A similar project I've been using for working with DAWs (audio recording / real-time effects) is https://xanmod.org/ Not sure how it compares to liquorix, but xanmod allowed me to go from 60ms+ to <10ms in pipewire latency.
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
If anyone has tried this on arch I'd love to hear your experience... I've got a home server sitting in my living room that looks bored.
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): 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 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.
Earlier quoted context omitted.
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): https://wiki.archlinux.org/title/kernel
> it's normally slower for server-workloads 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 Sure there are still some batch workloads or other non-latency sensitive things around, but I'd almost expect those to be i…
>If you for example are targeting Ah yes absolutely, if that needs that to be guaranteed maybe even real-time.
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. https://www.kernel.org/doc/html/latest/process/stable-kernel...
Earlier quoted context omitted.
So, mostly slower than stock Linux 5.4.6? That's quite disappointing.
Which is really weird. All the speedups they list seem like it would run faster in general. 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).
Earlier quoted context omitted.
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. https://www.kernel.org/doc/html/latest/process/stable-kernel...
I should try to narrow it down but will have to set aside some time to try a few kernels and see which patch it was, which is hard when I'm using it.
https://wiki.debian.org/DebianKernel/GitBisect
Tip from it: use the Debian wayback machine to do the first narrowing down: