You are not logged in.
So , i built up a custom kernel disabling everything i wouldn't need in menuconfig. Then ran some basic hardinfo Benchmarks, here are the results :
ARCH - ArchMod
CPU Zlib - Higher is better - ArchMod Wins
23980,942 - 25687,237
CPU Fibonacci - Lower is better - ArchMod Looses
3,605 - 3,667
CPU MD5 - Lower is better - ArchMod Wins
58,565 - 57,569
CPU SHA1 - Lower is better - ArchMod Wins
89,392 - 87,686
CPU Blowfish - Lower is better - ArchMod Looses
14,342 - 14,579
FPU Raytracing - Lower is better - ArchMod Wins
8,459 - 8,339
Kernel has Newer Xeon support enabled and is EMT64T enabled, running an x86_64 Arch
Comp Specs : Toshiba M800-10C
2,26 Ghz Penryn Intel core 2
4 gb RAM (800 Mhz i think)
Intel 4500 MHD integrated GPU
Does anyone have any linux benchmarks to test on ?
Offline
I compile zen sources and find it to be faster and more responsive, using deadline scheduler and the zen-tune is helpful with only 1 core.
Offline
Hey Fan!
Eh, guessing by the specs that your pc is a laptop? Well, the biggest gain I've noticed with a minimal kernel my battery lasts longer than the default kernel. Other than that and the faster boot times, performance gains are minimal, At least in my experience.
Offline
If your building a custom kernel to get more speed you will be disappointed. You are running the same code if its built in or modular it does not matter, disabling stuff you dont use... well you didnt use it before so again it wont make any difference.
The only place you will make minor gains is by enabling Cpu specific optimizations and in the case of Zen kernels native optimizations (at the cost of potential stability issues), both of which will probably net you at best a 5% gain and in the case of the Zen optimizations losses in other areas.
Best reasons to build a custom kernel are, the stock does not support your hardware fully, you need to enable a feature not in the stock kernel, you want to add patches to the kernel.
Offline
I find a kernel optimized for architecture to be slightly, slightly faster when using CPU heavy apps. Not noticable on normal use. Also, I found that the Vanilla sources work better with wine than the Arch kernel patches Seals the deal for me. And of course because all the cool kids do so.
Offline
I found that the Vanilla sources work better with wine than the Arch kernel patches
Anything specific?
Offline
I find a kernel optimized for architecture to be slightly, slightly faster when using CPU heavy apps. Not noticable on normal use. Also, I found that the Vanilla sources work better with wine than the Arch kernel patches
Seals the deal for me. And of course because all the cool kids do so.
On the other hand, some packages on Arch are kernel-specific (those which have kernel module components) and it can be a pain to manage these packages when you have a custom built kernel.
I built the kernel26-ice package so that I could have tuxonice suspend-to-disk (which works BRILLIANTLY and has done so for me for years on other distributions) - modified slightly by changing its kernel .config to match *exactly* that of the standard Arch kernel, except for the tuxonice specific parts - and afterwards it took me a while to figure out how to get VirtualBox to work again. Unfortunately the virtualbox modules package installs a module that only works for the stock Arch kernel, so you have to recompile the modules package yourself to get a kernel module that works for your own custom (in my case tuxonice) kernel. The annoying thing is that you have to modify the PKGINFO to get the resulting module to install into the correct place for the kernel you are building it for (this should be automatic in the PKGINFO in my opinion). Also I renamed the package (to virtualbox-modules-ice) so that it would not conflict with the standard VirtualBox kernel module package. Also it's annoying that the package has to rebuild a huge, huge virtualbox source tree just to emit a single kernel module file; surely there is a shorter path for building that module than the entire virtual box source tree!
There may be other packages which require kernel modules that you'd have to manually rebuilt if you use a custom kernel. For me, this makes using your own custom kernel highly undesirable; it's much, much easier to maintain your system when you don't have to muck with building other custom packages to work with your special kernel. However, sometimes you just can't get around it, because there are features that you need (such as tuxonice) that the standard kernel does not provide.
Offline
Themaister wrote:I found that the Vanilla sources work better with wine than the Arch kernel patches
Anything specific?
Well, this was a rather blunt statement, but going from -ARCH to vanilla I noticed more stable fps in some 3D-games, especially WoW (still using the ARCH kernel config though, with slight mods). Might not be the case for others.
Last edited by Themaister (2008-12-25 03:20:32)
Offline
Hey everyone! I was just doing some boot timing on my Dell Laptop.
INITRD seems to comlpete aroudn 8.9 seconds and a full timed boot to GDM login is around 23.4 seconds.
Won't custom building a Kernel and new initrd speed up the boot process at least a little bit? If initrd is smaller it should load much quicker but not necessary make your apps run quicker.
Anyone else got some boot times to share? (my laptop is E6400)
My Linux & Progamming Blog - Jimmy Burnett
Offline
The gains are usually trivial and not worth the effort. Consider what happens in the future when the kernel needs to be upgraded again. The only times that building a custom kernel makes sense is to provide better hardware support or to fix problems with software.
I recall needing to build a custom kernel on fedora + nvidia because the nvidia driver wouldn't work with 4k and a scsi board that required a module marked as broken in debian. The original eeepc lacked kernel support for more than 1gb of ram and that required a custom kernel. Some SQL servers required special kernel tweaking to operate properly.
Getting 5% more performance is nothing to sneeze at if the gain is guaranteed and stable. However, various studies have shown very little average change in performance. I prefer stability to performance and would surrender 5% performance for greater stability. Nothing is more frustrating than having your computer spontaneously reboot or freeze while using it, especially if your work is damaged in the process.
Last edited by davidgurvich (2010-03-25 14:36:58)
Offline
I also created a custom kernel for the eeepc because the wlan-driver wasn't supported by archlinux as I got my eeepc. Now I stay with my custom config and compile always the most recent vanilla just because I have a perfect config and there's no loss in doing so, also if the gain is little. But also I noticed a bit longer battery-time on the eeepc. It jumped from 2-3h to 4-5h.
@jimburnettva: 8.9secs is pretty long on archlinux. I think even my full encrypted eeepc doesn't need that much time... maybe do you start all deamons in foreground? There's nearly !no daemon! which needs to be run in foreground, thus you can really boost your boottime, just by starting the daemons in the background. Just add an @ sign in front of each daemon in your rc.conf
Last edited by Rorschach (2010-03-25 20:37:03)
Offline
I have found patched kernel with Brainfuck works really well in a desktop enviroment, you do notice it is a little more snappy
Certified Android Junkie
Arch 64
Offline
I also am a big fan of the BFS by -ck. Especially with the autoiso-xorg.patch which REALLY makes the desktop to be responsive even under heavy load (with both cpu intensive and io intensive tasks). Highly recommended, see kernel26-ck or kernel26-bfs in the aur. The second includes the autoiso patch.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
Yes, the -bfs patch does make quite some difference.
In my case for audio work I also use -rt sometimes.
Just removing unneeded modules doesn't help you though, honestly. Its a VERY minimal difference. If you need a particular patchset go for it, if not its not worth the time (except for education).
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
The zen kernel patchset also includes the BFS and the autoiso-xorg patch.
...and tuxonice! So it is a good all-in-one solution.
Last edited by SanskritFritz (2010-03-26 10:22:45)
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
BTW, can we gain some compile time by disabling every module and feature not needed? I found it to consume way too much time, shuffling through the options, and trying to understand what those pesky explanations mean... so I am yet to try this. In theory, when I have a good config, I can keep it, and reuse it when new versions come out.
Compiling a kernel takes some hours here.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
You can gain a lot of time if you only compile what you need (a stripped-down kernel for ARM platform here only takes a few minutes to build), but as you say it can be VERY time-consuming to go through every option.
You can also parallelize the build if you have a multi-core by issuing "export CONCURRENCY_LEVEL=2" before "make"
V=RI sweet V=RI
Offline
There is no such place as 127.0.0.1
Ber, thanks for the useful tip! Some minutes you say? I must dig into the config... I am the type, who actually likes to spend hours to save seconds of repetitive workload later.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
SanskritFritz, have a look at this: http://kernel-seeds.org/
Offline
my custom kernel is not really faster than default but in my case it helped:
- cut down boot time in a half (from 33s to 15s)
- less memory usage (I have better use for memory)
- enhanced security
- better interactivity (bfs/sio)
- simpler (no panic for several years)
Offline
bangkok_manouel interesting, thanks.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
My experience (for the little it's worth) is that yes it is worth it. My machine is now much more responsive after choosing a rt kernel (which I think also has bfs but I could be wrong) from the AUR and using that. It was pretty damn easy too. Ran a couple of commands, left the terminal doing its thing while I had a cup of tea and surfed the net, fixed /boot/grub/menu.lst (mostly through copy pasta), rebooted and suddenly had a beautifully fast and responsive computer. No more lock-ups. It's awesome, and I'd highly recommend it (and I'm a noob at kernel stuff so if it worked for me it'll work for any idiot).
PS I'd like to thank ngoonee for putting together the kernel26-rt-ice package on AUR, you did a fantastic job, and my computer is very grateful too
Last edited by Nerd King (2010-03-28 04:26:34)
Please be patient, I'm a n00b on Arch (only 2 years on Ubuntu) so I may say something stupid!
PS thank you to all those who contribute awesomeness to the AUR and the main packages, you guys have made my computer so much more fun to use!
Offline
My experience (for the little it's worth) is that yes it is worth it. My machine is now much more responsive after choosing a rt kernel (which I think also has bfs but I could be wrong) from the AUR and using that. It was pretty damn easy too. Ran a couple of commands, left the terminal doing its thing while I had a cup of tea and surfed the net, fixed /boot/grub/menu.lst (mostly through copy pasta), rebooted and suddenly had a beautifully fast and responsive computer. No more lock-ups. It's awesome, and I'd highly recommend it (and I'm a noob at kernel stuff so if it worked for me it'll work for any idiot).
PS I'd like to thank ngoonee for putting together the kernel26-rt-ice package on AUR, you did a fantastic job, and my computer is very grateful too
You're welcome. Its not my work though, as the PKGBUILD mentions I just copy off kernel26-ice, which is primarily maintained by iceman81 (myself and Evans contribute a bit as well).
And for clarity's sake, there's no BFS on that kernel, the -bfs and -rt patchset are incompatible with each other since they're both alternative implementations of the same thing (schedulers).
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
ngoonee
http://ck.kolivas.org/patches/bfs/2.6.3 … -315.patch is among the sources. Not executed though in the PKGBUILD as far as I see. A remnant?
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
What patches are better?
bfs of ck? I know both are made by Colivas, but what are their differences?
Offline