Soul Singin' wrote: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.
Oooh! Touchy touchy.
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.
damentz wrote:Soul Singin', using boot charts as the premise for argument ...
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:... and asserting that the build times I pasted are not objective ...
If you really believe that this is an objective test:
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.
then please let me know what you're smoking because I wanna try some of that!
damentz wrote:... makes you unqualified to further debate any kernel comparisons until you do some investigations and benchmarks of your own.
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:However, everyone else and I are very doubtful that you will follow through with anything useful ...
As if I know nothing about Debian and do not contribute anything around here.
damentz wrote:... due to your past behavior and off topic riots; all you can do is talk smack.
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.
Instead of admitting your fault however, you dismissed my legitimate concerns as:
damentz wrote:childish remarks
and inserted profanity into one of my posts by altering an image that linked to your website.
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!
note: I revised the definitions of the process time categories in an earlier post. My kernel builds an allnoconfig kernel 7 seconds faster than debians.
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.