Which LTS kernel for low latency ice1712 card on asus m2n32-SLI board

Why? those old audiophile 24/96 cards have nice sound and are worth getting working for some audio recording/creation work, and while the 6000+ cpu is power hungry it is still quite fast.

first problem I noticed was the cpu power stepping causing problems so disabled cool and quiet in bios, so the 14.x lts kernels work at moderate latency

Kernel 5.X does not seem to work, get lots of audio glitches

The older kernels are not compiled with the timer_hz=1000 option

also whilst they say pre-empt the actual option name in the config seems different though that could just be changes in nomenclature

I’m thinking I probably want to take one of those 14.x LTS kernels and generate a custom kernel build from that base, then any updates to that kernel will be posted via pamac so I can rebuild it for security backports… so probably the 4.19 kernel best as longest LTS from today

a) make ice1712 driver in the kernel not module (probably all modules for this mobo and devices I use in kernel)

b) set timer to 1000hz

c) maybe even compile the kernel optimised for this cpu generation, whilst I read an article saying no gain in doing that, that test was done with latest cpu’s, I’m thinking the gains may be better for my old cpu.

d) just generally “scientifically” mess with kernel options, there is loads of stuff in modern kernel this board does not need, but I guess as modules that is not so important, so probably just concentrate on the main gain areas for very low latency audio maybe test full RT option

So, which kernel would you recommend as the base, and are you planning on supporting those kernels as long as LTS dates

Also do you have a good guide for building a kernel the manjaro way.

:+1: Welcome to Manjaro! :+1:

You’re a prime candidate for the RT (Real-time) kernels. Use the:

  • kernel GUI program
  • mhwd-kernel CLI program

to try out all of our currently supported RT kernels and see which works best for you:

mhwd-kernel --list

available kernels:

  • linux414
  • linux419
  • linux44
  • linux49
  • linux54
  • linux57
  • linux58
  • linux59
  • linux54-rt
  • linux56-rt
  • linux59-rt

Manjaro follows the upstream kernel EOL dates religiously.

:+1:

already have, quite extensively.

my conclusion is the 5 series does not work well on this old hardware… 5 series regularly locks up (black screen of death) and when rebooting fails to reboot until pc turned off. I re-enabled virtualisation and cool and quiet in the bios and on the 4 series kernels (except manjaro 4.19 is not compiled with preempt) reasonable latency after setting performance cpu governer and no lockups (except rosegarden when going from auto clock source) reboots ok

there’s a few holes, like I tried to install the nvidia custom driver for 8800gt when running LTS 5.4 and the 4 series LTS and it said can’t find it for linux 5.8… well, I wasn’t trying to install it for flipping linux 5.8, what’s it doing telling me I cannot install it for 5.8… (thats another problem, that old nvidia driver has been deprecated) reading around someone said they removed latest kernel and it worked, but I can see all kinds of potential knots with that kind of thing…

but i really like the openbox orang theme… why on earth is that not in every desktop??? foreground window has nice bright orange bar LOL (actually first came across similar orange theme in debian ages ago and never saw it since)

it is my opinion distro need to pick a kernel and say this is last kernel for that hardware set and support it for N years from now…

no problems about trying to back support old hardware in future kernels except critical security backports… that’s my opinion…

(well of course then you get into the problem of having to test those old kernels for a critical bug found in later kernels, and was the critical bug only introduced by changes made in later kernels… or even actual existing hardware problems… comes a point you have to say this hardware no longer supported… as effort to fix it does not justify use of it… it still works but… use old version but do not connect it to the internet… or leave your pc unattended without arming the laser sentry guns LOL)

I guess a key feature is the hard identification of the distro download, it still needs to be supported… the web of trust eh! That classic paper “reflections on trusting trust” eh! by one of the C designers eh!

I guess the essence is, don’t say this supports old hardware when it doesn’t… as it hasn’t been tested on older hardware of the myriad configurations… whereas an old kernel is solid and may not need any of the new improvements made to kernel for later hardware… (not meant as a criticism of manjaro, rolling distributions are tricky, if you are developing for the leading edge, totally awesome!)

As you never provided an inxi --admin --verbosity=7 --filter --no-host --width I can’t tell you for sure, but this smells like you need something like Debian which is better suited for old hardware. Rolling releases are great for brand new spanking hardware.

Debian has its disadvantages too as you’ll also be running with old software on that old kernel… But it’s rock stable…

There is no perfect answer for your use case…

:sob:

Yes, Thanks, I mean it is nearly there with availability of the older LTS kernels in Manjaro, (and arch), just some extra work required to factor in the extra complications in the distro that will ensure that a user can select an LTS kernel, and older nvidia driver packs for those LTS kernels, and furthermore tweak kernel a bit, but still automatically get the latest versions of software until such time as that kernel becomes too tricky to support. It may be that the stable branch of manjaro and arch is moving too fast, and you need an ultra-stable branch.

Anyway I will have a crack at compiling the 4.19 kernel with pkgbuild as the 4.14 kernel has a couple of startup errors relating to the known amd problem with the amd64 spectre mitigation and retpoline and removing the latest 5 series kernels and see if it works OK. It’s a useful learning experience.

If not I may try all the extra work required in arch to get a desktop up and running, maybe gentoo is what I need to squeeze all the available cycles out of this old machine and not be loaded with bloat I do not need, it’s a cost benefit thing, how long is it going to take for what benefit over just using debian.

I know my old gaming-rig PC is OK, as I just spent 5 hours solid (where did that go?) playing company of heroes on the machine in windows LOL. Still a great game!

And I do think manjaro is a good distro.

1 Like

As a comparison I eventually got a really old athlon single core at 1400mhz PC of mine to boot having forgotten even what OS was on it, turned out it was a really old xubuntu on an LVM pair of disks, the problem was some extra sanity checks on volume access dates and having reset the bios (flipping bios backup battery problems, how many times has that stumped people… 2.8v old battery level… 3.3v for fresh… been not turned on for years…)

anyway in only 512mb of ram this old xubuntu kernel 2.6 was up and zippy, that is to say, considering its age it felt like a quite responsive computer…

I guess modern generic (all things to all people) linux is a bit like rimmers salute… doing about 5 times too many loops to get to the point… (If you have seen Red Dwarf that might make sense…)

also, is it true? compiling the kernel and modules with microsoft or intels (for intel) compiler makes it a lot faster, I know from ages ago the microsoft floating point operations were way faster than the borland compiler, I was told by an expert, tested it and it was true…

edit: I checked a 2017 article and g++ was second to intel (for intel) compilers

Ah! It just occurred to me, 64bit is one of those buzzwords that is actually not always better than 32 bit, in the case of slow 800mhz memory bus and only a requirement to do 32 bit flops on 32bit audio data you are probably shifting twice as much data around in memory as you require when doing 64 bit operations… I’ll try a 32 bit distro…

OK, after some testing and extracting salient points from this post and the archived post referenced and the arch wiki turns out it’s quite easy to compile your kernel

  1. /etc/makepkg.conf

CFLAGS="-march=native -O2 -pipe -fstack-protector-strong -fno-plt"
CXXFLAGS="${CFLAGS}"

(though thats arch method setting cxx to cflags, manjaro duplicates the line)

  1. download the manjaro source

git clone https://gitlab.manjaro.org/packages/core/linux414.git

  1. test you can build it as it is

cd linux414
makepkg -Csri

couple of hours later, enter password and install it, reboot and test it works

  1. edit PKGBUILD

after the line “make prepare” add line with “make nconfig”

(if you start adding patches then need to also run updpkgsums)

make -Csri

(-C is important as makepkg fails if patches already applied)

set your kernel parameters in the menus when nconfig starts

exit and let system build

and there you go, custom kernel, in my case with preempt now enabled in 419 and jack audio now stable with 5ms latency at 96khz

footnote:

The archived manjaro article referenced with post by anon23612428 describes adding your own version suffix for having a new entry in grub which is well worth doing, I tried that first but them was getting errors because patches had already been applied causing makepkg to fail which threw me for a while… so yet to do it properly but just reading up on the myriad kernel options to get a more optimised kernel for next attempt.

(Funny, saw an article saying "Kernel 5.2 released with 500,000 new lines of code, theres plenty to… enjoy!.. , I thought, plenty to slow yer old computer down LOL, no but it is a stunning achievement to support so much stuff purely by enthusiasts for free eh! )

I’d rather try to resolve that part. Maybe check if it happens on AV Linux which also uses 5.4 series kernel. Maybe contact the community of that distribution?

see footnote 2…

seems to me you have to read the kernel histories and say what benefit does 5.x give me on this PC? None I think! for next N years anyway…

If you provided the inxi output I might try :wink:

1 Like

yeah, OK, could be useful to actually try and debug it so this hardware still supported when 4.19 expires or should there be some useful feature appear in 5.x series. Do you need all the tools installed that give detailed inxi info…

The distro I used was the openbox “community” distro

I did notice a couple of ACPI warnings about data point sizes with this bios version, I checked and I had flashed it to latest 5002 but last few versions for this mobo all labelled “beta”

I was mostly joking.

I don’t know what I need, I would maybe enter the errors or warnings in the search engine and see if I find something.
inxi would give some hints about the setup, not just the hardware.

Apart from hardware I would argue that some filesystem improvements might be in 5.4 which aren’t in 4.19.

1 Like

I think only if you have a recent series computer, most stable distro’s are on 4.19 so that has got a lot of bug fixing collective-force on it for near future…

I mean, generic linux is that good that in the logs (journalctl is cool) it told me my graphics card, 8800gt, was capable of running twice as fast as it could, think that may be because the card only runs at that speed…

been some scathing comments on acpi by experts…

like I said some ACPI errors in all linux boots I have tested on this board, 64/32 bit complexities and I wonder if stepping back to last non beta bios on this old, at the time what I thought, ultra cost-effective gaming rig build board might be best ??? (to find out it was a waste of time???)

as long as google keeps turning up good results to technical questions, things are bright in the cave… (LOL)

OK little update

  1. reckon possibly this bios has an error only apparent in this (awesome-o, but large and extravagant, extravagantly quiet LOL, but still stupid extra connection required for capacitive touch sensor power button, cosmos-s) case, all large slow case fans and bios has fan speed low warning (600 minimum) that possibly tests before all these fans get up to speed and then bios goes beepety flipping beep and stops and no warning message on the display… strewth! (or could be drawing too much power through mobo thing)

  2. installing ubuntu studio f’d the grub bootloader, arch boots ubuntu, ubuntu does not boot arch (microcode thing) manjaro instructions to restore grub worked OK

  3. ubuntu studio way slower than running apps on this manjaro compiled kernel… lots of xruns on u.s. at same jack settings. march=native is effective or just this manjaro/arch got less guff installed. (possibly as ubuntu studio uses kernel 5.4) ?

  4. messing around with bios versions was a waste of time except discovering a quite mature linux based bios update program called flashrom, slight stomach flutter as the program took longer than expected but, all good! (make sure your board supported according to their instructions)

  5. and not sure if the the kernel option timer_hz (not found it yet, not looked much) is important if you are using jackd… muse seems quite stable once you figure its idiosyncrasies… nice software!

running onboard audio at 10ms 1 dropout (due to muse f’up) in about 5 hours… obviously I shut conky down as one of first things I did after installation of this distro, using top cpu is 96% idle playing midi through soft-synth in muse with qsynth fluidsynth (yes you need to load that up first) front-end running in jack… nice… I wonder if top is compiled to default to quad core as sum of cpu use says 20% but its 95% idle… could be just process times are peak in period and sum is more averaged…

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.