Package Details: linux-lqx-docs 6.14.3.lqx1-1

Git Clone URL: https://aur.archlinux.org/linux-lqx.git (read-only, click to copy)
Package Base: linux-lqx
Description: Documentation for the Linux Liquorix kernel
Upstream URL: https://liquorix.net/
Keywords: bbr2 bfq futex pds proton zen
Licenses: GPL-2.0-only
Submitter: akurei
Maintainer: sir_lucjan (damentz)
Last Packager: damentz
Votes: 165
Popularity: 2.09
First Submitted: 2011-08-08 16:08 (UTC)
Last Updated: 2025-04-20 18:28 (UTC)

Pinned Comments

damentz commented on 2020-08-31 15:22 (UTC) (edited on 2021-12-21 18:25 (UTC) by damentz)

Official binaries of linux-lqx, linux-lqx-headers, and linux-lqx-docs are now available: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#liquorix

Signing key import instructions: sudo pacman-key --keyserver hkps://keyserver.ubuntu.com --recv-keys 9AE4078033F8024D && sudo pacman-key --lsign-key 9AE4078033F8024D

Latest Comments

« First ‹ Previous 1 .. 22 23 24 25 26 27 28 29 30 31 32 .. 122 Next › Last »

damentz commented on 2018-11-18 18:39 (UTC) (edited on 2018-11-18 18:40 (UTC) by damentz)

@Terence, that's good information. While you were comparing results, I was measuring the overhead of 1000hz vs 250hz.

With 250hz, the timer consumes about 2-3ms, every second. Increasing this to 1000hz almost quadruples it. At idle, the timer tick consumes 8ms/s, but 5ms/s when the system is under full load (highest frequency). 8ms is less than 1% of the cpu usage of one core on a processor.

On the flip-side, one change I made with switching to 250hz is to re-instate a sampling down factor on ondemand. While the system is idle, it consumes about 3-5ms/s worth of processing to determine the next frequency. While the system is under full load, or near full load, ondemand consumes less than 1ms/s.

One thing I was wondering if you could try is adding rqshare=mc to your kernel parameters. Liquorix is currently configured with smt runqueue sharing, which improves throughput by looking for tasks in the order of cache locality. This might be influencing your underruns in a bad way.

Terence commented on 2018-11-18 15:22 (UTC)

@damentz I tried your suggestion but it didn't seem to improve things. I have between 3 and 4 times less xruns when using 1000Hz tick rate compared to the now default 250Hz. My test settings were a sample rate of 48000 Hz with 64 as the buffer size giving a latency of 1.3ms. I used the performance governor. I normally use 128 as the buffer size but I increased it in order to get more frequent xruns. An other observation is the schedutil is closer to the performance governor in terms of xruns at 1000Hz but there is a bigger gap between both at 250Hz.

I'm still wondering if it wouldn't make sense to keep 250hz as the default as my usage is quite an edge case I would say.

damentz commented on 2018-11-17 19:15 (UTC)

@Terence, try setting rr_interval back to 3 in /proc/sys/kernel. If that doesn't help, then it's the kernel tick frequency.

And thanks for reporting. Con has mentioned that the kernel tick frequency shouldn't matter and that MuQSS is "tickless". This may prove the opposite and that you still need a high frequency tick rate to support soft-realtime applications properly.

Let me know which of the two settings helps you the most - I'll update the configuration accordingly.

Terence commented on 2018-11-16 12:27 (UTC)

@damentz your changes introduced by https://github.com/damentz/liquorix-package/commit/d51bd77f2719e43528898a4db06af34aafd22bdf while being saner defaults degrades realtime audio/midi performances (more frequent xruns). Would only changing back the tick to 1000hz locally enough?

sir_lucjan commented on 2018-11-13 19:47 (UTC)

@Agafron:

Because 4.18.18-lqx patchset includes 4.18.18 from upstream.

Agafron commented on 2018-11-13 19:43 (UTC) (edited on 2018-11-13 19:49 (UTC) by Agafron)

Downloading linux-4.18.tar.xz

_major=4.18

_srcname=linux-${_major}

.........

source=("https://www.kernel.org/pub/linux/kernel/v4.x/${_srcname}.tar.xz"

Why is downloading linux-4.18.tar.xz instead of linux-4.18.18.tar.xz?

CybeX commented on 2018-11-13 10:00 (UTC) (edited on 2018-11-13 10:00 (UTC) by CybeX)

If anyone has an issue in building the kernel relating to:

 Verifying source file signatures with gpg...
    linux-4.18.tar ... FAILED (unknown public key 79BE3E4300411886)
==> ERROR:</font> One or more PGP signatures could not be verified!
Use the following:
gpg --keyserver hkps://pgp.mit.edu --recv-keys 79BE3E4300411886

gaougalos commented on 2018-11-10 17:16 (UTC)

When installing this kernel i get ERROR: module not found: `usbhid'

mapcode.mind commented on 2018-10-11 20:40 (UTC)

i'm happy to report that the package compiled and installed successfully. @damentz : your comment is informative; I didn't know that having not used makepkg before. I was unsuccessfully trying to edit the PKGBUILD variables to make it create the correct file. Thanks a lot for your input.

@sir_lucjan : about manjaro not being arch, i know that. I was thinking of using manjaro as a stepping stone towards arch, coming from a debian system. But, i have no complaints with the system i have now. Nor can i figure out a compelling enough reason to switch. In fact, this is the first issue i have had with aur since i installed manjaro, and i am pretty sure that this was an issue with aur helper yay and not manjaro itself. Thanks a lot for your comments and suggestions; they were really helpful.

damentz commented on 2018-10-11 20:29 (UTC) (edited on 2018-10-11 20:29 (UTC) by damentz)

There's probably multiple reasons why makepkg -sric solved your problem:

-s = --syncdeps - installs missing dependencies

-c = --clean - removes artifacts and work directories before building

-r = --rmdeps - removes installed dependecies required for build

It could just be you were missing dependencies and your work directory was dirty, had previous folders and files that were interfering with your build.