kernel-26-rt-ice or kernel26-zen?

edward.taylor89 · 2010-10-25 15:45:27

Hello,

I am writing this to try gather as much information on these two kernel patch-sets as much as I possibly can from the forums(as there aren't any archwiki's on both) before making a decision, then subsequently implementing either in my system.

Four questions:

1. What are their notable differences?
2. Which of either performs better ice or zen in terms of boot-time and desktop responsiveness?
3. Most importantly, are either of these better than the stock kernel?

Thanks in advance

Anonymo · 2010-10-25 16:36:28

1. The rt-ice has the real-time patch. (http://www.captain.at/howto-linux-real-time-patch.php). Information for the zen kernel sources are here: http://zen-kernel.org/about.
2. I don't really know, but I imagine Zen is better for desktop responsiveness.
3. I would not say they are better. They can be though. With other kernels, I always experience some sort of freezes on the system, since many of the features used can be experimental (not as well tested or finalized) and not part of the kernel yet. Never had this with the stock kernel. Plus, kernel26-zen is out of date in AUR and with rt-ice, it's using a 2.6.33 kernel. I believe that rt is mostly used my audio people. There are other options though. There's the kernel26-lqx kernel with has patches by damentz, usually used in Debian systems (http://liquorix.net/). Then there is the kernel26-pf kernel (http://pf-kernel.org.ua/) and there is kernel26-ck (http://users.on.net/~ckolivas/kernel/), which graysky has added many compile options too and is more up to date than the stock kernel. There is also kernel26-bfs, that only contains the bfs scheduler.
4. There is no fourth question.

The only way to see which one works best for you is to try them.

See also: http://wiki.archlinux.org/index.php/Ker … in_the_AUR

Last edited by Anonymo (2010-10-25 16:43:26)

broch · 2010-10-25 16:38:47

zen is set of experimental patches that may or may not to be beneficial. Very nice but might be overwhelming. Worth to try (but read first).
kernel26-rt-ice - in AUR refers to older kernel 2.6.33
even if updated, it shows of lack of understanding what rt and what bfs is (these are patches with quite opposite goal), even though with effort one could put rt and bfs together this makes no sense if you would try to enable rt and bfs together. Either get rt only or bfs only. It really depends what you want to do.

boot time? wrong question: read about requirements for faster boot on the forum.

hope this will help a little

Last edited by broch (2010-10-25 16:41:36)

SanskritFritz · 2010-10-25 16:50:40

kernel26-zen is outdated, use kernel26zen-git stable branch, it has the latest BFS integrated (it shows up in make menuconfig nicely along with the xorg iso patch).

graysky · 2010-10-25 20:23:29

You can also give kernel26-ck a try... ck1 patchset + optional BFQ scheduler. PDQ if you asked me

ngoonee · 2010-10-25 22:43:32

broch wrote:

zen is set of experimental patches that may or may not to be beneficial. Very nice but might be overwhelming. Worth to try (but read first).
kernel26-rt-ice - in AUR refers to older kernel 2.6.33
even if updated, it shows of lack of understanding what rt and what bfs is (these are patches with quite opposite goal), even though with effort one could put rt and bfs together this makes no sense if you would try to enable rt and bfs together. Either get rt only or bfs only. It really depends what you want to do.

As maintainer for kernel26-rt-ice, I'd just like to clarify broch's points.

The rt-patch only exists for 2.6.33, not for later versions of kernel26.

Also, as mentioned prominently in the PKGBUILD, kernel26-rt-ice is sourced directly from kernel26-ice. The PKGBUILD has modifiable flags where you can select various patchsets (bfs, rt, and others). They are not applied together.

All of this is explained in the AUR page, please don't make quick conclusions just based on an AUR search if you've never looked at the package.

edward.taylor89 · 2010-10-25 23:05:26

Isn't a 'Vanilla kernel' a stripped down kernel? Kernel26-ck is described as one.

Before installing a kernel with, for example, a BFS patch, will I have to no longer append 'elevator=deadline' from my GRUB kernel line?

I understand that the 'deadline' scheduler is a HDD scheduler and that 'BFS' and 'CFK' are CPU schedulers.

Sounds like I'll have another project to occupy myself with this weekend.

@Anonymo

Yes, there is no fourth question. That was me removing a question, irrelevant to the post title, but forgetting to change 'fourth' to 'third'! .

edward.taylor89 · 2010-10-25 23:06:36

'four' to 'three' even..

graysky · 2010-10-25 23:13:34

edward.taylor89 wrote:

Isn't a 'Vanilla kernel' a stripped down kernel? Kernel26-ck is described as one.
Before installing a kernel with, for example, a BFS patch, will I have to no longer append 'elevator=deadline' from my GRUB kernel line?
I understand that the 'deadline' scheduler is a HDD scheduler and that 'BFS' and 'CFK' are CPU schedulers.
Sounds like I'll have another project to occupy myself with this weekend.
@Anonymo
Yes, there is no fourth question. That was me removing a question, irrelevant to the post title, but forgetting to change 'fourth' to 'third'! .

The vanilla kernel is the -ARCH kernel. Vanilla meaning it's what the distro uses. That grub line you mention must switch your IO scheduler to deadline? If you enable the BFQ scheduler then you should remove that line from your grub entry since BFQ is an IO scheduler. Otherwise, leave it. BFS is a CPU scheduler as you pointed out. The CK1 patchset includes the BFS and other stuff from CK himself.

Weekend project? No, just download and makepkg -s to get the Arch kernel + BFS. You can edit the PKGBUILD's flags to toggle on BFQ if you wish and/or a menuconfig to further customize if you wish.

Anonymo · 2010-10-25 23:57:03

Can you guys add more descriptions of your kernels here:
http://wiki.archlinux.org/index.php/Ker … in_the_AUR

broch · 2010-10-26 03:20:38

Vanilla meaning it's what the distro uses.

no vanilla is ...vanilla:
www.kernel.org

no home brewed patches

otherwise any kernel/piece of software is vanilla for anyone trying to modify it: so if there is heavily modified kernel and you will patch it further, vanilla kernel is one that you take for further modification. Which makes no sense because someone may ask about vanilla-vanilla-vanilla kernel which is whatever-upstream-not-necessary-kernel.org-kernel

regarding boot time: within 6 mos arch managed to slowdown 5 sec from 12s boot time to 17s boot time and this is not kernel related (same kernel tested). Mostly init taking more and more time. Soon it will catch windows 7 starter edition (netbook) boot time.

The PKGBUILD has modifiable flags where you can select various patchsets (bfs, rt, and others). They are not applied together.

shrug one can set -rf and -bfs, there is nothing, no warning at all that these patches should not be used together.
thank god this package is out of date

Last edited by broch (2010-10-26 04:31:11)

Anonymo · 2010-10-26 04:14:49

broch wrote:

Vanilla meaning it's what the distro uses.
no vanilla is ...vanilla:
www.kernel.org
no home brewed patches
otherwise any kernel/piece of software is vanilla for anyone trying to modify it: so if there is heavily modified kernel and you will patch it further, vanilla kernel is one that you take for further modification. Which makes no sense because someone may ask about vanilla-vanilla-vanilla kernel which is whatever-upstream-not-necessary-kernel.org-kernel
regarding boot time: within 6 mos arch managed to slowdown 5 sec from 12s boot time to 17s boot time and this is not kernel related (same kernel tested). Mostly init taking more and more time. Soon it will catch windows 7 starter edition (netbook) boot time.

http://aur.archlinux.org/packages.php?ID=24450

broch · 2010-10-26 04:40:25

Anonymo wrote:

broch wrote:
Vanilla meaning it's what the distro uses.
no vanilla is ...vanilla:
www.kernel.org
no home brewed patches
otherwise any kernel/piece of software is vanilla for anyone trying to modify it: so if there is heavily modified kernel and you will patch it further, vanilla kernel is one that you take for further modification. Which makes no sense because someone may ask about vanilla-vanilla-vanilla kernel which is whatever-upstream-not-necessary-kernel.org-kernel
regarding boot time: within 6 mos arch managed to slowdown 5 sec from 12s boot time to 17s boot time and this is not kernel related (same kernel tested). Mostly init taking more and more time. Soon it will catch windows 7 starter edition (netbook) boot time.
http://aur.archlinux.org/packages.php?ID=24450

one more time:

Vanilla meaning it's what the distro uses.

wrong explanation:

I could say
Zen meaning it's what the distro uses.
http://aur.archlinux.org/packages.php?ID=30330

this is also wrong statement. Arch uses neither zen nor vanilla, but you can install either if you want. Make it yourself or get from AUR (Arch User Repository)

ngoonee · 2010-10-26 05:13:38

broch wrote:

The PKGBUILD has modifiable flags where you can select various patchsets (bfs, rt, and others). They are not applied together.
shrug one can set -rf and -bfs, there is nothing, no warning at all that these patches should not be used together.
thank god this package is out of date

The fact that the patches won't apply isn't warning enough? And you obviously ignored the rest of my post, since I explain that the package is not out-of-date. You should know, as you've expressed your opinions on the rt patch-set quite a few times before round here. Unless of course you don't actually use it....

broch · 2010-10-26 12:20:04

well you did express (few times) opinion that one can use -rt and bfs. which is wrong and thank God this breaks if applied together.
Unless you have closed security holes that were found between 2.6.33 and 2.6.36, this package is out-of-date

Last edited by broch (2010-10-26 12:24:53)

Anonymo · 2010-10-26 13:40:07

broch wrote:

well you did express (few times) opinion that one can use -rt and bfs. which is wrong and thank God this breaks if applied together.
Unless you have closed security holes that were found between 2.6.33 and 2.6.36, this package is out-of-date

A lot of patchsets backport updates or install updates to the kernel they use. For example, with kernel26-lqx, I only use the base kernel (2.6.36.0) and apply the patch, and this brings it up to date to for example 2.6.36.5, because the patchset includes the updates. Also, just because it's a 2.6.33 kernel doesn't mean THE PACKAGE is out of date, if it's the latest version released by the -rt devs. The maintainer is up to date with the package that the -rt developers have released.

ngoonee · 2010-10-26 23:22:46

broch wrote:

well you did express (few times) opinion that one can use -rt and bfs. which is wrong and thank God this breaks if applied together.
Unless you have closed security holes that were found between 2.6.33 and 2.6.36, this package is out-of-date

Please indicate where I have expressed that opinion.

And I'm not sure why you choose to ignore my posts. Upstream has not released -rt patch for higher than 2.6.33, hence the package is not out-of-date (as Anonymo says). You're welcome to try porting the 2.6.33 patch to 2.6.36.

broch · 2010-10-27 15:01:40

ngoonee wrote:

broch wrote:
well you did express (few times) opinion that one can use -rt and bfs. which is wrong and thank God this breaks if applied together.
Unless you have closed security holes that were found between 2.6.33 and 2.6.36, this package is out-of-date
Please indicate where I have expressed that opinion.
And I'm not sure why you choose to ignore my posts. Upstream has not released -rt patch for higher than 2.6.33, hence the package is not out-of-date (as Anonymo says). You're welcome to try porting the 2.6.33 patch to 2.6.36.

1) post #10 in
https://bbs.archlinux.org/viewtopic.php?id=106086
and some more
2) worst defense ever: keeping kernel with security problems for the sake of -rt. Either back-port patches from 2.6.36 or mar this out-of-date (as every honest maintainer would do)

Anonymo · 2010-10-27 16:33:42

broch, I really think you need to examine or double check a lot of the things you are saying. Please, please, for the sake of uninformed users here, re-read everything before you post it.

Here is on point 1.

1)

ngoonee wrote:

sand_man wrote:
Does anyone know if BFS is a good replacement for -realtime patch for low latency audio production?
Its adequate, in that it allows lower-latencies without xruns than the standard kernel.
This is during audio-only though, I have not tested BFS with other apps running at the same time eating CPU. If -rt gives you 2 ms, BFS might give you 4 (just a random gauge of how 'low' you can go).

ngoonee never says to use both. He is making a comparison of -rt and BFS and the results the guy might get under each. The guy was asking if BFS was a replacement to -rt, not if he could use them together.

2) http://www.kernel.org/pub/linux/kernel/projects/rt/
The latest patch is 2.6.33.7 (released in August), which is the patch ngoonee uses.
http://kernel.org/ shows:

stable: 2.6.33.7 2010-08-02

This is the latest 2.6.33 kernel to be released by the devs. If you don't feel safe using it, don't. But the package cannot and should not be marked out of date just because it's not the latest kernel put out by the kernel devs. Ubuntu is using 2.6.32. Doesn't mean it's out of date. 2.6.33 is still offered on the kernel.org main page, so someone is maintaining it still.
Feel free to post any patches to the 2.6.33 kernel that you find will help with any vulnerabilities.

Last edited by Anonymo (2010-10-27 16:35:06)

broch · 2010-10-27 18:12:02

-rt patch
if they can't get -rt for 2.6.36 then because of security issues this should be removed flagged outdated irrelevant of what you think about -rt.
argument about Ubuntu using 2.6.32 - it has all patches for 2.6.36 backported to 2.6.32, all distros do this if they do not upgrade kernels between cycles.
www.kernel.org has 2.6.33.7 from 2010-08-02 it is your responsability (if still using this kernel) backport patch that for example fixes this:
http://secunia.com/advisories/41462/

This is quite simple.

The guy was asking if BFS was a replacement to -rt, not if he could use them together.

and his answer is

Its adequate, in that it allows lower-latencies without xruns than the standard kernel.

which is incorrect, check out differences between -rt and bfs. If both work for you then you can forget about either as well because you don't need for your purpose anything better than default Arch kernel.

ngoonee · 2010-10-28 01:39:57

I'm not sure why you've arbitrarily decided that kernel26-rt-ice doesn't use 2.6.33.6. Once again, please check before making such claims, patch-2.6.33.7.bz2 is clearly shown in the sources. I'm not a kernel hacker and will not be backporting any fixes beyond what is received from upstream, and as an AUR maintainer that's not my job. Arch is not Debian. By your logic kernel26-lts should be removed from the repos, since its obviously dangerous to use.

Do you even use Jack? On my machine you can get lower xruns with bfs as compared to an identical stock kernel configuration. As I said in that thread, not as low as with -rt, but still lower than stock.

broch · 2010-10-28 04:17:36

I'm not sure why you've arbitrarily decided that kernel26-rt-ice doesn't use 2.6.33.6. Once again, please check before making such claims, patch-2.6.33.7.bz2

you lost me here what are you talking about?
first of all it does not matter if you use 2.6.33.6 or 2.6.33.7
second of all your kernel is 2.6.33.7 after patch-2.6.33.7 was applied.

both (2.6.33.6 and 2.6.33.7) have holes.

second of all where did I mention 2.6.33.6? and why you are mentioning this?

Now try to understand if not difficult that 2.6.33.7 is dated 2010-08-02

now today is 2010-10-27. Look at secunia link I provided
See?
there is a hole published on 2010-09-15 this is not fixed in 2.6.33.6 or 2.6.33.7 or whatever 2.6.33.x you want to use.

if you do not understand that anything below 2.6.36 has security issues (unless - one more time - backported patches were applied), you should not touch kernel.

Now If you can't backport security fix then you should list kernel as out-of-date because this is now dangerous to use anything that is not patched.

here you have an example from Fedora:
they backported 2.6.36 patches to current Fedora kernel 2.6.32
http://lwn.net/Alerts/406406/

if you still do not understand security issue that you have with then I really suggest to give up kernel for other users sake.

I only hope that you will not get confused again asking where did I get the impression that you are using 2.6.32. This is only an example of fixing a serious problem.

To make sure: you have 2.6.33.7 that needs fixing.

with -rt jack can run with the highest priority, and other processes will not interfere. BFS does exactly the opposite. This meant that BFS will give all processes equal priority which means that because you can't control other processes, jack audio quality will suffer.

Last edited by broch (2010-10-28 04:19:06)

ngoonee · 2010-10-28 05:13:13

AUR maintainers don't typically write their own patches for the packages they maintain (especially for something such as the kernel). Bringing up Fedora or Debian's list of patches doesn't make sense, they're humongous distros with the resources to allocate. Arch isn't, and you know that full well.

Or, in other words, I follow upstream. Upstream releases 2.6.33.7, I apply it. Does the resulting kernel have security holes? Of course. So do most of the other kernels in the AUR which are ONLY 2.6.35 currently. Why not delete all kernel26-* packages then?

And once again, do you use Jack? Please test it out with the bfs patch on your system vs the normal kernel patch. BFS prevents hogging by processes, and a byproduct of that is better performance of jack on a system with low load. It works differently from -rt, but for audio work its not the theories that matter, its the user-facing result.

broch · 2010-10-28 19:40:25

Bringing up Fedora or Debian's list of patches doesn't make sense, they're humongous distros with the resources to allocate. Arch isn't, and you know that full well.

that is why arch is getting the latest to avoid different issues (e.g. security problems) while Fedora keep patching kernel. end effect is the same: gained security. That is not the case of your stuff.

Or, in other words, I follow upstream. Upstream releases 2.6.33.7, I apply it. Does the resulting kernel have security holes? Of course. So do most of the other kernels in the AUR which are ONLY 2.6.35 currently. Why not delete all kernel26-* packages then?

pretty childish argument: there are responsible maintainers who updated kernels already, there are irresponsible maindatners who did not.
yes, software with security issues (not only kernel) should be removed by any decent, honest package maintainer.

-rt vs bfs
http://forums.gentoo.org/viewtopic-t-820452.html

BFS is to an RT system what a Ford V8 engine is to a Formula 1. You first need to give the engine to Cosworth and then... not forget about breaks, tires

reason why I don't use -rt (for audio) anymore you need much more than kernel and cpu scheduler is not enough to get good results.

that is all

ChoK · 2010-10-28 20:19:11

Users are warned that they use AUR at their own risks. Arch AUR users are/should be aware that running an outdated kernel is a security risks. Still, let them use 2.6.33, .34 or whatever it's their system, don't take their choices away.

Arch Linux

#1 2010-10-25 15:45:27

kernel-26-rt-ice or kernel26-zen?

#2 2010-10-25 16:36:28

Re: kernel-26-rt-ice or kernel26-zen?

#3 2010-10-25 16:38:47

Re: kernel-26-rt-ice or kernel26-zen?

#4 2010-10-25 16:50:40

Re: kernel-26-rt-ice or kernel26-zen?

#5 2010-10-25 20:23:29

Re: kernel-26-rt-ice or kernel26-zen?

#6 2010-10-25 22:43:32

Re: kernel-26-rt-ice or kernel26-zen?

#7 2010-10-25 23:05:26

Re: kernel-26-rt-ice or kernel26-zen?

#8 2010-10-25 23:06:36

Re: kernel-26-rt-ice or kernel26-zen?

#9 2010-10-25 23:13:34

Re: kernel-26-rt-ice or kernel26-zen?

#10 2010-10-25 23:57:03

Re: kernel-26-rt-ice or kernel26-zen?

#11 2010-10-26 03:20:38

Re: kernel-26-rt-ice or kernel26-zen?

#12 2010-10-26 04:14:49

Re: kernel-26-rt-ice or kernel26-zen?

#13 2010-10-26 04:40:25

Re: kernel-26-rt-ice or kernel26-zen?

#14 2010-10-26 05:13:38

Re: kernel-26-rt-ice or kernel26-zen?

#15 2010-10-26 12:20:04

Re: kernel-26-rt-ice or kernel26-zen?

#16 2010-10-26 13:40:07

Re: kernel-26-rt-ice or kernel26-zen?

#17 2010-10-26 23:22:46

Re: kernel-26-rt-ice or kernel26-zen?

#18 2010-10-27 15:01:40

Re: kernel-26-rt-ice or kernel26-zen?

#19 2010-10-27 16:33:42

Re: kernel-26-rt-ice or kernel26-zen?

#20 2010-10-27 18:12:02

Re: kernel-26-rt-ice or kernel26-zen?

#21 2010-10-28 01:39:57

Re: kernel-26-rt-ice or kernel26-zen?

#22 2010-10-28 04:17:36

Re: kernel-26-rt-ice or kernel26-zen?

#23 2010-10-28 05:13:13

Re: kernel-26-rt-ice or kernel26-zen?

#24 2010-10-28 19:40:25

Re: kernel-26-rt-ice or kernel26-zen?

#25 2010-10-28 20:19:11

Re: kernel-26-rt-ice or kernel26-zen?

Board footer