Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Alternative Performance Kernel for Debian
- craigevil
- Posts: 5391
- Joined: 2006-09-17 03:17
- Location: heaven
- Has thanked: 28 times
- Been thanked: 39 times
Re: Alternative Performance Kernel for Debian
All I can say is the liquorix kernel is much more responsive on my crappy system than the debian kernel.
$ inxi -F
System: Host craigevil Kernel 2.6.31-1.dmz.1-liquorix-686 i686 (32 bit) Distro Debian GNU/Linux squeeze/sid
CPU: Single core Intel Pentium 4 (UP) cache 1024 KB flags (sse3 nx lm) bmips 5593.51
Clock Speeds: (1) 2793.104 MHz (2) 2793.104 MHz
Graphics: Card Intel 82915G/GV/910GL Integrated Graphics Controller X.Org 1.6.3.901 Res: 1280x1024@60.0hz
GLX Renderer Mesa DRI Intel 915G GEM 20090712 2009Q2 RC3 x86/MMX/SSE2 GLX Version 1.4 Mesa 7.5.1 Direct Rendering Yes
Audio: Card Intel 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller driver HDA Intel
Sound: Advanced Linux Sound Architecture Version 1.0.21
Network: Card Intel 82562ET/EZ/GT/GZ - PRO/100 VE (LOM) Ethernet Controller driver e100 at port dcc0
Disks: HDD Total Size: 160.0GB (9.6% used) 1: /dev/sda WDC WD1600JS-75N 160.0GB
Partition: ID:/ size: 103G used: 15G (15%)
Info: Processes 101 Uptime 5 min Memory 120.6/493.5MB Client Shell inxi 1.1.13
$ inxi -F
System: Host craigevil Kernel 2.6.31-1.dmz.1-liquorix-686 i686 (32 bit) Distro Debian GNU/Linux squeeze/sid
CPU: Single core Intel Pentium 4 (UP) cache 1024 KB flags (sse3 nx lm) bmips 5593.51
Clock Speeds: (1) 2793.104 MHz (2) 2793.104 MHz
Graphics: Card Intel 82915G/GV/910GL Integrated Graphics Controller X.Org 1.6.3.901 Res: 1280x1024@60.0hz
GLX Renderer Mesa DRI Intel 915G GEM 20090712 2009Q2 RC3 x86/MMX/SSE2 GLX Version 1.4 Mesa 7.5.1 Direct Rendering Yes
Audio: Card Intel 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller driver HDA Intel
Sound: Advanced Linux Sound Architecture Version 1.0.21
Network: Card Intel 82562ET/EZ/GT/GZ - PRO/100 VE (LOM) Ethernet Controller driver e100 at port dcc0
Disks: HDD Total Size: 160.0GB (9.6% used) 1: /dev/sda WDC WD1600JS-75N 160.0GB
Partition: ID:/ size: 103G used: 15G (15%)
Info: Processes 101 Uptime 5 min Memory 120.6/493.5MB Client Shell inxi 1.1.13
Raspberry PI 400 Distro: Raspberry Pi OS Base: Debian Sid Kernel: 5.15.69-v8+ aarch64 DE: MATE Ram 4GB
Debian - "If you can't apt install something, it isn't useful or doesn't exist"
My Giant Sources.list
Debian - "If you can't apt install something, it isn't useful or doesn't exist"
My Giant Sources.list
Re: Alternative Performance Kernel for Debian
Debian kernel is set up for servers. It boggles the mind why they don't offer a desktop kernel (or am I wrong about this?)
Ubuntu hate is a mental derangement.
Re: Alternative Performance Kernel for Debian
how so, could you bootchart or time some processes using the debian kernel and then using the liquorix kernel?craigevil wrote:....much more responsive ....
Re: Alternative Performance Kernel for Debian
Liquorix uses full preemption without preemptable RCU, so it should certainly provide less latencies than debian kernel, which uses no preemption (besides what the kernel does by design to reduce latency).
I would prefer the latter, which is where Liquorix comes in.
You're not wrong; either they should balance the kernel configuration in debian to provide a bit less latency at the cost of more overhead or build two kernels that are optimized for their stated purpose.AdrianTM wrote:Debian kernel is set up for servers. It boggles the mind why they don't offer a desktop kernel (or am I wrong about this?)
I would prefer the latter, which is where Liquorix comes in.
Re: Alternative Performance Kernel for Debian
...any numbers to show the improvement in performance?
Re: Alternative Performance Kernel for Debian
Code: Select all
liquorix 2.6.31-1.dmz.2
real 0m58.328s
user 1m33.332s
sys 0m14.866s
debian 2.6.30
real 1m5.057s
user 1m31.282s
sys 0m14.525s
To explain why the user time is longer for the liquorix kernel... well I was surfing the web and talking to friends at the same time . The debian 2.6.30 kernel was on a clean boot to the gnome desktop with no arbitrary apps running.
Some definitions, real: total wall clock elapsed time - user: process time outside of kernel - sys: process time making kernel calls.
In this case, sys time is higher for the liquorix kernel is most likely due to full preemption, while debian uses none.
Last edited by damentz on 2009-09-29 05:51, edited 3 times in total.
Re: Alternative Performance Kernel for Debian
i wrote:gnudude wrote:...any numbers to show the improvement in performance?
my stock debian kernel needs ~30 boottime.with liquorix its (boottime) 14 seconds,
besides that pure numbers it really feels very responsive, fast and stabel.
on another note:
for me its not big fun moving allready compiled kernels around between different hard-disks, qemu and virtualbox.
installing liqourix goes in the blink of an eye.
And i too am not of the ones who think the biggest fun ever is compiling a kernel on your own.
Its good and useful. Thanks
greetings
- Soul Singin'
- Posts: 1605
- Joined: 2008-12-21 07:02
Re: Alternative Performance Kernel for Debian
damentz wrote:To explain why the user time is longer for the liquorix kernel... well I was surfing the web and talking to friends at the same time . The debian 2.6.30 kernel was on a clean boot to the gnome desktop with no arbitrary apps running.
In other words, you are so incompetent that you cannot even perform the simplest of all objective comparisons.
Amazing.
I do not know how Jalu timed his boot, but (at the very least) his comparison appears objective. You couldn't do the same?
Let me spell it out for you:
Code: Select all
$ su
Password:
# apt-get update
# apt-get install bootchart bootchart-view
# apt-get clean
# exit
Code: Select all
init=/sbin/bootchartd
After you have logged back in, run:
Code: Select all
$ bootchart /var/log/bootchart.tgz
Repeat the process with the other kernel. Then we'll have an objective comparison.
.
Re: Alternative Performance Kernel for Debian
I don't take requests from trolls, do the benchmarks yourself.Soul Singin' wrote:damentz wrote:To explain why the user time is longer for the liquorix kernel... well I was surfing the web and talking to friends at the same time . The debian 2.6.30 kernel was on a clean boot to the gnome desktop with no arbitrary apps running.
In other words, you are so incompetent that you cannot even perform the simplest of all objective comparisons.
Amazing.
I do not know how Jalu timed his boot, but (at the very least) his comparison appears objective. You couldn't do the same?
Let me spell it out for you:
Reboot and append:Code: Select all
$ su Password: # apt-get update # apt-get install bootchart bootchart-view # apt-get clean # exit
to GRUB's kernel line.Code: Select all
init=/sbin/bootchartd
After you have logged back in, run:Post the bootchart.png file in this thread, so that we can see the length of time it took to boot your system.Code: Select all
$ bootchart /var/log/bootchart.tgz
Repeat the process with the other kernel. Then we'll have an objective comparison.
.
- Soul Singin'
- Posts: 1605
- Joined: 2008-12-21 07:02
Re: Alternative Performance Kernel for Debian
How can you claim that your kernel is faster if you haven't made an objective comparison?damentz wrote:do the benchmarks yourself.
.
Re: Alternative Performance Kernel for Debian
That's called "marketing" and it happens everyday.Soul Singin' wrote:How can you claim that your kernel is faster if you haven't made an objective comparison?
Re: Alternative Performance Kernel for Debian
Here are the boot charts -> http://liquorix.net/test
The debian kernel finishes booting within 21 seconds while the Liquorix kernels finish at 24 or 25, depending on the disk scheduler.
It seems that with the Liquorix kernels, more things run concurrently while with Debian's, large tasks are complete in batches and cause some other services to take ages to complete (wicd jumps out as one of the major ones) at the benefit for throughput. The order of services run is also much different between the two kernels.
The larger boot times are expected with Liquorix due to more emphasis on sync latency rather than throughput. That would explain why some users find this kernel snappier under higher disk load than debian's.
Soul Singin', using boot charts as the premise for argument and asserting that the build times I pasted are not objective makes you unqualified to further debate any kernel comparisons until you do some investigations and benchmarks of your own. However, everyone else and I are very doubtful that you will follow through with anything useful due to your past behavior and off topic riots; all you can do is talk smack.
I did try the build benchmark again, though, and the results are the same and simply prove that there's more overhead from preemption on the liquorix kernel and your critical eye over dust is nothing but a waste of time.
Also note that the Liquorix kernel renices X to -10, which can steal cpu time from batch/bulk tasks if they need to update the screen for drawing updates (gnome-terminal and etc).
The debian kernel finishes booting within 21 seconds while the Liquorix kernels finish at 24 or 25, depending on the disk scheduler.
It seems that with the Liquorix kernels, more things run concurrently while with Debian's, large tasks are complete in batches and cause some other services to take ages to complete (wicd jumps out as one of the major ones) at the benefit for throughput. The order of services run is also much different between the two kernels.
The larger boot times are expected with Liquorix due to more emphasis on sync latency rather than throughput. That would explain why some users find this kernel snappier under higher disk load than debian's.
Soul Singin', using boot charts as the premise for argument and asserting that the build times I pasted are not objective makes you unqualified to further debate any kernel comparisons until you do some investigations and benchmarks of your own. However, everyone else and I are very doubtful that you will follow through with anything useful due to your past behavior and off topic riots; all you can do is talk smack.
I did try the build benchmark again, though, and the results are the same and simply prove that there's more overhead from preemption on the liquorix kernel and your critical eye over dust is nothing but a waste of time.
Code: Select all
real 0m58.923s
user 1m33.054s
sys 0m14.208s
Re: Alternative Performance Kernel for Debian
thanks for those...
I am kind of stumped though....is there any way to see the performance improvement that your kernels provide?
Maybe a script that starts up a number of heavy apps and times each of them?
Or maybe some bootchart profiling of some heavy applications or the system for a certain amount of time?
I am kind of stumped though....is there any way to see the performance improvement that your kernels provide?
Maybe a script that starts up a number of heavy apps and times each of them?
Or maybe some bootchart profiling of some heavy applications or the system for a certain amount of time?
Re: Alternative Performance Kernel for Debian
Anything regarding latency, Liquorix will shine. Building a kernel and bootchart are throughput benchmarks. I'm surprised that the kernel real build time is much less than debian's, however.
It's hard to benchmark interactivity latency, but there are some benchmark tools that were used when comparing BFS and CFS (where BFS raped CFS regarding average latency deadlines).
To put it into perspective, the debian kernel has less ticks per second under workload and 4x higher target latency with CFS. Also since X is not niced, the latency for gui apps is much higher. This provides an ideal setup for a server that is only interacted with remote shells.
With disk usage, the disk scheduler for debian does not drain the NCQ hardware on hard drives to fullfill a sync task with lowest latency, instead it can sit in queue for seconds instead of milliseconds allowing tasks of less seek penalty to be done first (sometimes prevent the sync task from running for quite some time).
If anyone is surprised that the throughput is less than debian's, well... your bad.
It's hard to benchmark interactivity latency, but there are some benchmark tools that were used when comparing BFS and CFS (where BFS raped CFS regarding average latency deadlines).
To put it into perspective, the debian kernel has less ticks per second under workload and 4x higher target latency with CFS. Also since X is not niced, the latency for gui apps is much higher. This provides an ideal setup for a server that is only interacted with remote shells.
With disk usage, the disk scheduler for debian does not drain the NCQ hardware on hard drives to fullfill a sync task with lowest latency, instead it can sit in queue for seconds instead of milliseconds allowing tasks of less seek penalty to be done first (sometimes prevent the sync task from running for quite some time).
If anyone is surprised that the throughput is less than debian's, well... your bad.
- Soul Singin'
- Posts: 1605
- Joined: 2008-12-21 07:02
Re: Alternative Performance Kernel for Debian
Oooh! Touchy touchy.damentz wrote:Soul Singin', ... everyone else and I are very doubtful that you will follow through with anything useful due to your past behavior and off topic riots; all you can do is talk smack.
Could that be because your own tests show that your "Alternative Performance Kernel" is slower than the stock Debian kernel?
damentz wrote:The debian kernel finishes booting within 21 seconds while the Liquorix kernels finish at 24 or 25, depending on the disk scheduler.
Look, I'm willing to concede that your kernel may shine through in areas other than boot time, but you have not told us what areas those are. Your vague references to "latency" are not a substitute for a concrete example.damentz wrote:Soul Singin', using boot charts as the premise for argument ...
If you really believe that this is an objective test:damentz wrote:... and asserting that the build times I pasted are not objective ...
then please let me know what you're smoking because I wanna try some of that!damentz wrote:To explain why the user time is longer for the liquorix kernel... well I was surfing the web and talking to friends at the same time . The debian 2.6.30 kernel was on a clean boot to the gnome desktop with no arbitrary apps running.
If I had surplus hardware, I would happily set up a Debian Sid system and perform some tests of my own. The fact that I do not have surplus hardware however does not mean that I can't spot a bad test (such as the one you performed).damentz wrote:... makes you unqualified to further debate any kernel comparisons until you do some investigations and benchmarks of your own.
As if I know nothing about Debian and do not contribute anything around here.damentz wrote:However, everyone else and I are very doubtful that you will follow through with anything useful ...
You began this thread by claiming that a three-week old, untested scheduler was "stable." All I did was warn everyone that the scheduler's author specifically stated that it isn't stable.damentz wrote:... due to your past behavior and off topic riots; all you can do is talk smack.
Instead of admitting your fault however, you dismissed my legitimate concerns as:
and inserted profanity into one of my posts by altering an image that linked to your website.damentz wrote:childish remarks
So, if you're wondering why flames keep consuming your thread, it's because you keep throwing gasoline on the fire.
The difference between you and me is that I openly admit to flaming you, while you engage in sneak attacks and pretend to be a victim. I have no sympathy for you.
.
Re: Alternative Performance Kernel for Debian
Soul Singin' wrote:Oooh! Touchy touchy.damentz wrote:Soul Singin', ... everyone else and I are very doubtful that you will follow through with anything useful due to your past behavior and off topic riots; all you can do is talk smack.
Could that be because your own tests show that your "Alternative Performance Kernel" is slower than the stock Debian kernel?
damentz wrote:The debian kernel finishes booting within 21 seconds while the Liquorix kernels finish at 24 or 25, depending on the disk scheduler.Look, I'm willing to concede that your kernel may shine through in areas other than boot time, but you have not told us what areas those are. Your vague references to "latency" are not a substitute for a concrete example.damentz wrote:Soul Singin', using boot charts as the premise for argument ...
If you really believe that this is an objective test:damentz wrote:... and asserting that the build times I pasted are not objective ...then please let me know what you're smoking because I wanna try some of that!damentz wrote:To explain why the user time is longer for the liquorix kernel... well I was surfing the web and talking to friends at the same time . The debian 2.6.30 kernel was on a clean boot to the gnome desktop with no arbitrary apps running.
If I had surplus hardware, I would happily set up a Debian Sid system and perform some tests of my own. The fact that I do not have surplus hardware however does not mean that I can't spot a bad test (such as the one you performed).damentz wrote:... makes you unqualified to further debate any kernel comparisons until you do some investigations and benchmarks of your own.
As if I know nothing about Debian and do not contribute anything around here.damentz wrote:However, everyone else and I are very doubtful that you will follow through with anything useful ...
You began this thread by claiming that a three-week old, untested scheduler was "stable." All I did was warn everyone that the scheduler's author specifically stated that it isn't stable.damentz wrote:... due to your past behavior and off topic riots; all you can do is talk smack.
Instead of admitting your fault however, you dismissed my legitimate concerns as:and inserted profanity into one of my posts by altering an image that linked to your website.damentz wrote:childish remarks
So, if you're wondering why flames keep consuming your thread, it's because you keep throwing gasoline on the fire.
The difference between you and me is that I openly admit to flaming you, while you engage in sneak attacks and pretend to be a victim. I have no sympathy for you.
.
Your blatant ignorance for how the time binary works is reminiscent of the sidux developers believing CONFIG_TIMER_STATISTICS measurably reduces battery life.
Your inability to comprehend the consequence of reduced latency + full preemption versus throughput is strikingly similar to a monkey discovering that bananas are yellow.
Your ability to correlate the lack of surplus hardware with spotting unmeasurable margins of error is simply off topic, completely false, and fuel for flames.
Your assumption that your post count for some reason makes you more important than anyone else here is pompous and arrogant, a quick skim through some posts outside of this thread show that other users think you're sarcastic and ignorant.
Your desire for credit for protecting everyone from the evil Brainfuck Scheduler is selfish and also very inaccurate. My decisions do not have any references to noise and squeaky wheels.
And last, DOUCHEBAG is not listed as profane in any english dictionary. You are delusional and appear to be exaggerating the most trivial aspects which are completely unimportant to everyone except your obsessive compulsive disorder to fix something that was never broken.
You're off topic, unqualified to speak, and a major flaming douchebag - shut up. I'm not kidding -> http://www.urbandictionary.com/define.p ... =douchebag
Why you can't understand that a desktop optimized kernel is tuned for latency rather than throughput is impossible for someone that spams as hard as you do on a linux forum.
---------------------------------
Back to topic
If Con's latest bug fix works well, BFS will be in my kernel again permanently.
BFS v240 benchmarks of make allnoconfig with 2.6.31
Code: Select all
real 0m58.705s <-- real elapsed time
user 1m32.329s
sys 0m9.788s <-- whoa!
You can see here that the compile time is roughly the same and that the kernel overhead has dropped significantly. The debian kernel still falls behind with 1m and 5 seconds.
EDIT: Spoke with con regarding sys time, BFS uses different cpu time accounting methods which are more accurate than CFS, so they report incomparable numbers. Real time is the only way to really safely compare two different schedulers here.
Last edited by damentz on 2009-09-29 06:19, edited 2 times in total.
Re: Alternative Performance Kernel for Debian
How does using your kernel benefit me? Where/how can I feel or measure the performance improvements? What is going to be better for me if I use this kernel?
Give me a action I can perform that will show the performance improvement please.
Give me a action I can perform that will show the performance improvement please.
Re: Alternative Performance Kernel for Debian
Reduce the latency of ALSA and play music while playing a game. You can try putting the following in ~/.asoundrc or /etc/asound.confgnudude wrote:How does using your kernel benefit me? Where/how can I feel or measure the performance improvements? What is going to be better for me if I use this kernel?
Give me a action I can perform that will show the performance improvement please.
Code: Select all
defaults.pcm.rate_converter "speexrate_medium"
defaults.pcm.dmix.rate 44100
defaults.pcm.dmix.format "S32_LE"
defaults.pcm.dmix.period_size 256
pcm.!default {
type plug
slave.pcm "dmixer"
}
pcm.dsp0 {
type plug
slave.pcm "dmixer"
}
pcm.dmixer {
type dmix
ipc_key 1024
ipc_key_add_uid 0
slave {
pcm "hw:0,0"
period_size 256
buffer_size 2048
format S32_LE
rate 44100
}
}
ctl.dmixer {
type hw
card 0
}
Another tip is to try playing a multiplayer online game with high sensitivity to lag. My favorite is warsow which is extra sensitive - on my favorite online server, I reduced the average latency down to 49-50ms where it used to be about 60-70ms. Better scheduler deadlines cause smoother gameplay, which in turn result in lower average net latency for the game (which depends on frame rendering deadlines).
Other than that, just using your system like a power user and abuse its resources. Run 'dd if=/dev/sda of=/dev/null bs=2M count=1000' while loading firefox and browsing for some files in your home directory. Just do something uncommon that would usually mess up the stock debian kernel.
Also, your desktop, if 2d, should feel just a tad snappier, but that's all how fast your perception is. Being a twitch FPS gamer, I'm sensitive to these changes myself, but quantitative evidence is hard to come up for such random things.
- Soul Singin'
- Posts: 1605
- Joined: 2008-12-21 07:02
Re: Alternative Performance Kernel for Debian
.
My accusation:
Your admission of guilt:
My accusation:
Soul Singin' wrote:... and inserted profanity into one of my posts by altering an image that linked to your website.
Your admission of guilt:
Quoted for truth.damentz wrote:And last, DOUCHEBAG is not listed as profane in any english dictionary.
.Soul Singin' wrote:... you engage in sneak attacks and pretend to be a victim. I have no sympathy for you.
Re: Alternative Performance Kernel for Debian
Soul Singin'. Stop this crap now.
damentz, do me a favor too and just ignore it.
And no, I'm not interested in who said what to whom or who started what. Just stop it.
damentz, do me a favor too and just ignore it.
And no, I'm not interested in who said what to whom or who started what. Just stop it.