Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

2.4 vs 2.6 Linux Kernel Shootout 533

Posted by michael from the bang-bang dept.
FyRE666 writes "Infoworld are currently running an interesting comparison of the 2.4 series kernel against the new 2.6 release on Xeon, Opteron and Itanium CPUs with some surprising benchmark results for common server-related tasks. Basically the new scheduler helps the 2.6 kernel to cream the old 2.4: Samba tests showing up to 73% speed increases, MySQL showing up to 29% and Apache serving dynamic content up to 47% faster!"
This discussion has been archived. No new comments can be posted.

2.4 vs 2.6 Linux Kernel Shootout More

2.4 vs 2.6 Linux Kernel Shootout

Comments Filter:

  • Error (Score:5, Informative)

    by popa ( 590190 ) * on Saturday January 31, 2004 @08:47PM (#8147461) Homepage
    tried to get this in before you posted it... but dynamic only went up 22% for apache.... static went up 47%

    • Real world vs. fanboy fantasies (Score:5, Funny)

      by Anonymous Coward on Saturday January 31, 2004 @09:34PM (#8147724)

      I am what most people would consider a highly trained technical professional. Unlike most people who spout off at this site, I have the certificates to prove this, and furthermore they're issued by the biggest software company in existence.

      I know how to tell facts from marketing fluff. Now, here are the facts as they're found by SEVERAL INDEPENDENT RESEARCH INSTITUTES:

      Expenses for file-server workloads under Windows, compared to LinuxOS:
      • Staffing expenses were 33.5% better.
      • Training costs were 32.3% better.


      They compared Microsofts IIS to the Linux 7.0 webserver. For Windows, the cost was only:
      • $40.25 per megabit of throughput per second.
      • $1.79 per peak request per second.


      Application development and support costs for Windows compared to an opensores solution like J2EE:
      • 28.2% less for large enterprises.
      • 25.0% less for medium organizations.


      A full Windows installation, compared to installing Linux, on an Enterprise Server boxen:
      • Is nearly three hours faster.
      • Requires 77% fewer steps.


      Compared to the best known opensores webserver "Red Hat", Microsoft IIS:
      • Has 276% better peak performance for static transactions.
      • Has 63% better peak performance for dynamic content.


      These are hard numbers and 100% FACTS! There are several more where these came from.

      Who do you think we professionals trust more?
      Reliable companies with tried and tested products, or that bedroom coder Thorwalds who publicly admits that he is in fact A HACKER???

      --
      Copyright (c) 2004 Mike Bouma, MCSE, MCDST, MS Office Specialist

      Permission is granted to copy, distribute and/or modify this document
      under the terms of the GNU Free Documentation License, Version 1.2
      or any later version published by the Free Software Foundation;
      with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
      Texts. A copy of the license is included in the section entitled "GNU
      Free Documentation License".

      • Re:Real world vs. fanboy fantasies (Score:2, Funny)

        by Anonymous Coward
        And who paid for that research, likely under the stipulation that they wouldn't pay for it if it didn't show results that Microsoft liked?

        Microsoft.

        You're living in a fantasy land if you think IIS is cheaper than or faster than apache 2.0.x
      • Its my experience that "highly trained technical professionals" would have enough real world experience to know the sort of crap code that can come out of any company...no matter how much money you throw at it, and that there's nothing inherently better about a product that costs money. In fact, it's been my experience that the more you pay for something, the crappier it is *cough*legato*cough*

        Also, professional you may be (as in you get payed to do it), but you have very little professionalism if you have

      • did I hear JOKE? (Score:3, Informative)

        by tasinet ( 747465 )
        i dont know if it's been posted already but check this [microsoft.com]. Aint no joke mister.
      • Unlike most people who spout off at this site, I have the certificates to prove this, and furthermore they're issued by the biggest software company in existence.

        Mike Bouma, MCSE, MCDST, MS Office Specialist

        You left off the C&C so you owe me a new keyboard.
      • Who do you think we professionals trust more?
        Reliable companies with tried and tested products, or that bedroom coder Thorwalds who publicly admits that he is in fact A HACKER???

        Hats off to you good sir! The funniest troll I've seen in a while. Actually had me about ready to engage in a shouting fit till that last line. Hilarious.

        Putting the post under a GPL, genius!

  • And SCO shows... (Score:4, Funny)

    by Black Parrot ( 19622 ) on Saturday January 31, 2004 @08:48PM (#8147474)


    ...a stunning 129% increase on SPEClawsuit!

  • Okay, so that's with the latest and greatest.. (Score:3, Interesting)

    by spitefulcrow ( 713858 ) <sam@dividezero.net> on Saturday January 31, 2004 @08:48PM (#8147476) Journal
    But how much of an improvement does it get on older hardware and/or software packages?
    • On older hardware, it isn't noticably better. But that's just because it was already fine on such hardware. For such hardware, the main interesting thing is that the CPU scheduler does a better job of recognizing tasks which need a bit of processor time at precise intervals, so that you can play audio and video without skips while under more total load.

      It should also help with the ~5ms delay when you interact with the system, so that it "feels better", regardless of the actual system speed.

      But these aren'
    • I tried 2.6.0-test8 when I had my Dual PII box a few months ago. Performance difference for KDE between it and my 800@920MHz spitfire Duron was pretty much unnoticeable. Recommended for older boxes.

      Also, for a more current comparison:

      distributed.net rc5-72 Duron 1.4@ 1.9 (2400+) w/256kb l2 cache mod:

      Windows: 5,500-6,000/sec
      Linux 2.4.20-debian: 3,400-3,700/sec
      Linux-2.6.1-rc1: 5,500-6,000/sec.

      The upgrade to Linux-2.6 is worth it.

  • drugs are bad (Score:5, Funny)

    by POds ( 241854 ) on Saturday January 31, 2004 @08:49PM (#8147477) Homepage Journal
    Okay, who's been feeding 2.6 speed?

  • May try it then (Score:4, Interesting)

    by Anonymous Coward on Saturday January 31, 2004 @08:49PM (#8147481)
    I was wondering about upgrading to 2.6 from 2.4 with XFS on my box, with the improvements to SCSI support and the CPU speed ups it sounds promising :D

    Then again BSD is very nice on the same hardware. Wonder how 2.6 linux & (free)BSD compare for those tasks.

    • Re:May try it then (Score:5, Informative)

      by anthonyrcalgary ( 622205 ) on Sunday February 01, 2004 @02:01AM (#8149127)
      Try them both to see which one is faster/you like more. And don't listen to anyone who tells you not to try the alternatives, they're probably zealots.

      Don't let my sig fool you, I like Gentoo better on the desktop. It's just that little bit more convenient to get the latest everything.

      Some stuff I can tell you:
      • With ULE enabled on FreeBSD 5.2, I can't tell the difference. No formal benchmarks, but I did everything I could to expose stuff that might annoy me later on. Dragging windows around really fast with "display content in moving windows" on and music playing. The sort of thing that would bring Linux 2.4 to its knees easily
      • FreeBSD 5.2 has some annoying things. Like you've got to manually enable the drivers for sound devices and USB mice. And you've got to recompile the kernel to get ext2 support. It's pretty easy and well documented, but you can't just install and have a working system with no additional work.
      • Gentoo didn't (for me) have any major issues. I mean, compile times can be a bitch, but you'll be doing that on FreeBSD eventually too.
      • FreeBSD can do some really nifty stuff that Linux can't. Like jails.
      My advice is to wait until FreeBSD 5 hits STABLE and Linux 2.6 matures a little bit, install both, and see what's more fun.

  • Impressive (Score:5, Interesting)

    by mgv ( 198488 ) <Nospam.01.slash2dotNO@SPAMveltman.org> on Saturday January 31, 2004 @08:50PM (#8147483) Homepage Journal
    These are impressive improvements.

    Its actuallly hard to believe that there is that much more improvement to be gained - it will leave the microsoft servers even further behind as I don't think that they are improving their kernel that fast.

    One question:

    Does this mean that we can see improvements in low end systems for desktop use, or is the benefit only for servers. Because if this helps low end machines, it extends further the number of machines that can move from (say) win 98 to a real OS, whose hardware has long been abandoned by microsoft.

    Michael

    • Re:Impressive (Score:5, Informative)

      by JebusIsLord ( 566856 ) on Saturday January 31, 2004 @09:07PM (#8147581)
      well i know the preemtive and low-latency changes (while available as patches to 2.4) are included in 2.6, and make a significant difference to GUI responsiveness.
      • I'm just done with the transition of my home box. Took a few hours to get everything up, needed patches for lirc support. But it seems very well. UT2003 runs like a god with zero hickups. The thing I like the most is the new build system in 2.6, much better checks of what need to be compiled. To insert a new thing in the kernel takes about 20sek compile compared to probaly 5-10 minutes on 2.4 on my XP1800+.

      • Re:Impressive (Score:5, Informative)

        by zmooc ( 33175 ) <zmooc@nOspaM.zmooc.net> on Saturday January 31, 2004 @10:02PM (#8147852) Homepage
        I can now watch divx on my pII-233 with it. Xmms never skips and X remains useable under high loads. It's an incredibly huge difference to 2.4. But I only noticed when I had to go back to 2.4.22 to try out openmosix. It was absolutely annoyingly slow compared to 2.6.

    • Re:Impressive (Score:4, Funny)

      by Serveert ( 102805 ) on Sunday February 01, 2004 @03:18AM (#8149461)
      The pre-emptible kernel(you must enable this, it's off by default) will blow your mind when using a GUI. It is beyond impressive, it's like you're neo and you can see the mouse pointer before it gets to where you move your mouse.

      You can grep your hard drive many times yet still browse the web with no slow down.

  • Linux in cache? (Score:4, Interesting)

    by SHEENmaster ( 581283 ) <{travis} {at} {utk.edu}> on Saturday January 31, 2004 @08:50PM (#8147488) Homepage Journal
    What I'd like to see is Linux that could run entirely within cache on the higher end chips. Even dated UltraSparcII chips can have up to 8M/cache. That's 64M in an 8-way box, allowing for some truly awe-inspiring performance on mathematical problems if RAM is ignored.

    I haven't looked into sparc assembly enough to know if this is possible.

    • Re:Linux in cache? (Score:5, Insightful)

      by ParisTG ( 106686 ) <tgwozdzNO@SPAMgmail.com> on Saturday January 31, 2004 @09:09PM (#8147593)
      Caching is controlled completely by the CPU, transparent of the programmer.

      Assuming that the kernel is the only code running, and it is small enough to fit into cache, then it will get there eventually.

      However, it would make no sense to keep the entire kernel in cache, since most of that code isn't used most of the time. Also, application software is running at the same time, which needs to be cached as well.

      In other words, just trust the CPU. It knows what it's doing :).

      • Re:Linux in cache? (Score:5, Informative)

        by runderwo ( 609077 ) <runderwo.mail@win@org> on Saturday January 31, 2004 @09:51PM (#8147797)
        Caching is controlled completely by the CPU, transparent of the programmer.
        Only in some designs. Architectures like MIPS allow for both a cache-coherent or non-cache-coherent design. In a non-cache-coherent design, the cache is not transparent, and the kernel programmer is responsible for cache management; marking pages as dirty, flushing cache, etc. These designs are significantly more difficult to program and are present on some SGI machines, making porting to those machines a significant task.

        Theoretically, higher performance can be achieved in a non-cache-coherent design, since the programmer would ostensibly know more about which data is most frequently used on his system and be able to customize his kernel for that. Also, it requires less glue logic on the board. However, the intent may be thwarted if the programmer doesn't have all the documentation (or skills) necessary to make efficient use of a software controlled cache.

      • Re:Linux in cache? (Score:5, Informative)

        by lars_stefan_axelsson ( 236283 ) on Sunday February 01, 2004 @02:06AM (#8149160) Homepage

        Caching is controlled completely by the CPU, transparent of the programmer.

        Not really true these days. Some architectures do have an explicit 'cache preload' instruction, such as the SPARC V9 and the ARM9E to mention two. These allow the programmer to preload a D-cache line before it is needed.

        As the speed of the CPU has increased much faster than the speed of main memory (and hence increasing the relative cost of a cache mis), compiler based techniques to emit cache preload instructions in advance, before the data is actually needed, has been the subject of some research in the past 7-8 years. The main reason to do it is software, instead of hardware, is that the compiler have a greater knowledge of the layout of the entire task, as it can 'look ahead' in the source code. The main disadvantage is that any static analysis, of course won't have access to dynamic (run time) data about the program as it is running.

        If you wish to go further, you could do worse than to start with my former colleague Magnus Karlsson's PhD thesis on the subject:

        Magnus Karlsson: "Data Prefetching Techniques Targeting Single and a Network of Processing Nodes". Ph. D. thesis, Department of Computer Engineering, Chalmers University of Technology, December 1999.

        And of course as always, Google and citeseer is your friend.

        In other words, just trust the CPU. It knows what it's doing :).

        Well, actually, it doesn't these days... :-) Trust the compiler instead :-) (Yeah, right).

    • Why would I want my AmigaFS modules in cache? Or anything that touches something slow like a hard-drive? The whole point of cache is so the code that gets used the most stays in cache. If certain kernel code gets used often enough, it'd stay in the cache.
      • This would not be for general use, it would be for running one specific, time-critical, application. If I'm going to sacrifice my 4G of ram to run everything in cache, it would not be to keep AmigaFS in my kernel.

  • My thoughts... (Score:4, Interesting)

    by big_groo ( 237634 ) <groovis.gmail@com> on Saturday January 31, 2004 @08:51PM (#8147494) Homepage
    I haven't noticed *any* differences on the desktop. ALSA is nice, kernel config is easier, but other than that...nothing noteworthy over 2.4.19 (my last kernel). Am I missing something? Oh, and I *still* can't get my USB mic to work (help!).

    Slackware with Dropline, btw. I do notice that Java tends to take up 250MB of RAM every once in a while while running Firebird. I didn't have that problem with 2.x.x.

    • Re:My thoughts... (Score:5, Interesting)

      by pacman on prozac ( 448607 ) on Saturday January 31, 2004 @08:59PM (#8147544)
      My thoughts were, wow, much faster. I'm now running 2.6 on all my desktop machines and it flies. They "seem" much more responsive with 2.6 than 2.4, especially under load.

      The initial boot time to load the kernel seems to have massively dropped although I could be imagining that.

      The new build system in 2.6 definately rocks, forgot to compile something important in? No need to wait for * to recompile anymore, just the vital parts are re-done.
      • I *thought* boot time was a bit faster, but I for some reason I thought it was just me. I guess it is a *bit* faster on boot. I honestly didn't see an appreciable increase in speed though. It just could be GNome :) (SMACK -1 troll, I know, but I don't use KDE)

        P4 2.2, 768MB RAM. NO swapping :).

        • I *thought* boot time was a bit faster, but I for some reason I thought it was just me. I guess it is a *bit* faster on boot. I honestly didn't see an appreciable increase in speed though. It just could be GNome :) (SMACK -1 troll, I know, but I don't use KDE)

          P4 2.2, 768MB RAM. NO swapping :).

          I think that your absense of a swap file may explain this. 2.6 works alot faster on disk I/O.

          This suggests to me that older low memory machines that use alot of swap file access may be much faster. Which would

      • Re:My thoughts... (Score:5, Interesting)

        by shadowbearer ( 554144 ) on Saturday January 31, 2004 @09:57PM (#8147822) Homepage Journal
        Ditto here. I've been running the -test kernels on the faster machine since summer, so I can't remember just how much difference there was. I do know it was noticeable, tho. In particular setiathome used to noticeably slow the machine; now I don't even notice whether it's running or not. *grin* 2.6 definitely WU'ed me there *grin*

        On the laptop I just compiled 2.6.1 for, however, (a 200mhz DEC HiNote) the speed increases are huge. You're not imagining the boot time drop - it's easily twice as fast on the laptop as 2.4.20 was. The GUI is also noticeably more responsive.

        The new build system is great, especially on a slow machine :) Kudos to the kernel people, and thanks!

        SB

    • Re:My thoughts... (Score:3, Informative)

      by echeslack ( 618016 )
      I don't notice any real speedups, but I do not really notice updatedb running anymore. Actually that's not entirely true, I just notice it a lot less. Many times it will run and I won't notice it. The mouse used to start getting all sticky when I had too much disk activity. Now it *mostly* runs smoothly.
    • I haven't noticed *any* differences on the desktop. ALSA is nice, kernel config is easier, but other than that...nothing noteworthy over 2.4.19 (my last kernel). Am I missing something?

      Well, it's not exactly something you notice on the desktop, but having LSM built into the kernel now is definitely a good thing. This is basically SELinux folded into the mainstream kernel - and the improved security available from that is impressive. It is the sort of thing you really OUGHT to be using, even on a desktop

    • Re:My thoughts... (Score:5, Informative)

      by owlstead ( 636356 ) on Saturday January 31, 2004 @09:28PM (#8147702)
      No, you aren't missing something. Applications will still run as they did, except when they are heavily multithreaded. Starting up something CPU-cycle expensive and typing in open office might give you an idea.

      But all in all, it's the kernel. End users should be nicely unaware of it. Don't expect any fireworks to go off, most of the time you notice a kernel you will have hoped you didn't :).

  • 2.6 on server? (Score:5, Insightful)

    by black666 ( 630792 ) on Saturday January 31, 2004 @08:54PM (#8147514) Homepage Journal
    Those benchmarks are nice, but who runs kernel 2.6 on production servers that need every speed they can get? It will be a few more 2.6.x releases until I consider running one of my servers with a 2.6 kernel.
    • Start planning, it's a safe bet they'll get there. Put a game server on 2.6 and see how it plays, or do something with a 2.6 box, you *will* be upgrading eventually.

    • Re:2.6 on server? (Score:4, Funny)

      by 1000StonedMonkeys ( 593519 ) on Saturday January 31, 2004 @11:35PM (#8148421)
      Well, yes, but it's a safe bet that the speed improvements in 2.6.0 won't disappear in later versions of the kernel.

    • 2.6 on server! (Score:3, Informative)

      by greppling ( 601175 )
      The fact is, 2.6 is considered extremely stable on servers by those who use it. (It's a little more problematic on the desktop where a big variety of hardware needs to be supported, and one of the drivers you need might not be so well-tested yet.)

      In fact, some of the more server-oriented developers were so content with the stability of 2.5 early on that they started making mild pushes towards a 2.6.0 release almost a year ago.

  • BSD Vs Linux Vs Windows 2k3 (Score:2, Insightful)

    by Anonymous Coward
    How does 2.6 compare to Free or Open BSD & how do they compare to windows 2003 server doing the same job?

  • NTFS Read/write support? (Score:5, Interesting)

    by lawpoop ( 604919 ) on Saturday January 31, 2004 @08:56PM (#8147526) Homepage Journal
    The chart on the first page [infoworld.com] says that 2.6 supports read and write for NTFS. Is this really the case? Does anyone trust NTFS writing if it's in the kernel?

  • It's shame, really. (Score:4, Funny)

    by Anonymous Coward on Saturday January 31, 2004 @08:57PM (#8147529)
    It's not Linux 2.6.x, it's SCO/Linux 2.6.1.

  • Also notable.... (Score:5, Interesting)

    by haggar ( 72771 ) on Saturday January 31, 2004 @08:57PM (#8147531) Homepage Journal
    ..is the parformance of the Opteron. Looks like Linux 2.6.x and Opteron are a great combo. Okay, I admit, I was a bit skeptical regarding Linux 2.6, but it seems it might actually deliver.

    I'm looking forward for Solaris + Opteron servers. Should be another interesting combo, performance wise. For one, Solaris 9 has some fantastic scheduling for multiprocessor machines. Additionally, it has been implemented in 64 bit for many years.

    • Re:Also notable.... (Score:4, Interesting)

      by Doomdark ( 136619 ) on Saturday January 31, 2004 @10:07PM (#8147878) Homepage Journal
      I'm looking forward for Solaris + Opteron servers. Should be another interesting combo, performance wise. For one, Solaris 9 has some fantastic scheduling for multiprocessor machines. Additionally, it has been implemented in 64 bit for many years.

      One potential concern, though, is that while there has been Solaris for x86 for a while, it's not really its main platform... so it's bit like waiting for 2.4.6 kernel on, say, Sparc systems. So I'm wondering if Solaris design of scheduling (and other kernel parts) takes some advantage of Sparc processor's design, that wouldn't map nicely into Opteron? In future this should get better (since Sun is now allied with AMD), but Solaris 9 was written probably well before x86 was seen as strategic platform for Sun.

  • From the article:

    For instance, a simple read of a 500MB file during a streaming write with a 1MB block size on my Xeon-based test system took 37 seconds with v2.4.23, and 3.9 seconds with v2.6.

    Huh? That just can't be right, can it?

    Also, a lot of us have been running with NPTL for some time now before shitcanning our Red Hat installs... I would've like to seen a comparison between 2.6 and a NPTL 2.4.

    • Re:I can't believe these results (Score:5, Insightful)

      by JumboMessiah ( 316083 ) on Saturday January 31, 2004 @09:13PM (#8147613)
      Actually, it wouldn't suprise me if this is correct. If you notice, he was reading the 500MB file while a continuous streaming write was going on in the background. On 2.4.x, a write streamout will kill read performance drastically. Mostly due to the way the I/O scheduler schedules the read. Which, most of the time, is to stash it at the end of the writes.

      The two new I/O schedulers in 2.6.x help to resolve this. For more info, check here [kerneltrap.org].

  • Good to know that. (Score:5, Funny)

    by nefele ( 654499 ) on Saturday January 31, 2004 @08:59PM (#8147545)
    So if I use the new and improved herbal 2.6 kernel my processing power will be UP TO 150% BIGGER and my UPTIME will be 200% LONGER!!
    And it's only $699 a box! ;-)

  • Time for some more FAIR benchmarks (Score:4, Insightful)

    by haruchai ( 17472 ) on Saturday January 31, 2004 @09:01PM (#8147556)
    I'd like to see how Linux 2.6 stacks up against Windows Server 2003 now. This time, let's have Microsoft and Redhat or some other Linux gurus go head to head.

    One of the good things of benchmarking at an early stage is that it may expose some hard to find weaknesses, much like the first Mindcraft tests exposed a kernel limitation which hampered Apache's performance.

  • Tests (Score:3, Insightful)

    by Sir Pallas ( 696783 ) on Saturday January 31, 2004 @09:10PM (#8147599) Homepage
    I guess it's important to ask the following question: was 2.4 ever designed to run on those kinds of processors? I mean, the O(1) scheduler is a pretty cool, processor independant change; but was 2.6 designed with specific optimizations for newer processors (and newer instructions) in mind? I'd be interested to see benchmarks from old hardware -- i.e., stuff like I've got sitting around. (If only I had a bit more time. Maybe I can borrow some cycles from 2.6 Linux boxen.)

    • Re:Tests (Score:3, Informative)

      by chunkwhite86 ( 593696 )
      I guess it's important to ask the following question: was 2.4 ever designed to run on those kinds of processors? I mean, the O(1) scheduler is a pretty cool, processor independant change; but was 2.6 designed with specific optimizations for newer processors (and newer instructions) in mind? I'd be interested to see benchmarks from old hardware -- i.e., stuff like I've got sitting around. (If only I had a bit more time. Maybe I can borrow some cycles from 2.6 Linux boxen.)

      I'm guessing that the answer is
  • These are some pretty encouraging results. The hard work put in by all the kernel developers has obviously paid off in a big way. However, after reading the article I still have a few questions about kernel 2.6 performance, namely filesystem performance. Rapid random read/write access is obviously highly critical for enterprise type applications, such as apt-get package management and package database updates. Basically with the 2.4.x series of kernels, filesystem performance using either the ext2 or ex

  • backports (Score:5, Informative)

    by POds ( 241854 ) on Saturday January 31, 2004 @09:18PM (#8147655) Homepage Journal
    for those who dont know, you've been able to get a back port [backports.org] of 2.6 on woody for the last month (almost).

    so go get it, and tell me how it will effect my surfing, emailing, mp3ing and general userish behavour on my P2 400 128RAM...

    Go on, get to it! :)

    • Re:backports (Score:5, Interesting)

      by shadowbearer ( 554144 ) on Saturday January 31, 2004 @09:48PM (#8147793) Homepage Journal

      I just compiled 2.6.1 for my 200mhz laptop (Debian unstable) and the speed increase - especially at boot and for Fluxbox - was very, very noticeable, particularly for cpu intensive apps.

      I haven't noticed any breakage - not yet - the machine has only been up for 4 days running 2.6.1. But so far it's great :)

      BTW I used the kernel source from debian, not the backport.

      A question for anyone out there with a Digital HiNote 7xx series laptop; any idea which sound chip it uses, and how to set up sound? Google hasn't been very informative. (Not a 2.6 problem, I can't figure out which driver to use; most people seem to be using old SB compatibility, but I can't make it work :( TIA )

      SB

  • Benchmark against vendor kernels? (Score:4, Informative)

    by salimma ( 115327 ) * on Saturday January 31, 2004 @09:29PM (#8147704) Homepage Journal
    No self-respecting large Linux distributor would ship a vanilla 2.4 kernel (well, SuSE does, but as an option, and not pre-compiled). The O(1) scheduler which AFAICT makes quite a large performance difference, has been available since RH9, IIRC, and presumably its contemporaries adopted it back then as well.

    So it's not such a big leap for real users. Mind you, still a big improvement - especially for interactive use, and also considering that there are so many patches for 2.4 that are now integrated into 2.6, lessening compatibility worries (try patching Red Hat's pre-FC1 2.4 kernel source).

    • I ran the -ck patches to 2.4 (they have a backported pre-empt, O(1), and low latency) before moving to 2.6. The -ck patches were noticably faster than vanilla 2.4 but 2.6 still crushes them on boot. 2.6 also seems a hair more responsive than 2.4-ck but I expected that.

      And I've never used a vendor kernel beyond booting the system and downloading/compiling my own.

  • just wait (Score:2, Funny)

    by Anonymous Coward
    I can't wait until the year 2007 when 2.6 finally moves to Debian stable.

  • 2.6 just didn't wow me (Score:3, Informative)

    by rsilvergun ( 571051 ) on Saturday January 31, 2004 @09:33PM (#8147722)
    on low end hardware at least. I've got an old Dell with a p200 and 64 megs of ram running Slackware 9.1. The processor could keep up but there's just not enough ram, even running a lightweight window manager like blackbox or XFCE. I'm not exactly trying to run uber-apps here (Abiword and Firebird mostly). Switching to 2.6 from 2.4 helped some, but not nearly enough. Funny thing is, I ran RH 6.2 on simularily configured I guess it bugs me because I was looking forward to showing my friends how I've got a modern desktop and applications running on an old P200. hardware. When did Linux become such a memeory hog? And to think I laughed when I saw Lindows' min sys requirements where a PIII 800.

    • I had a similar problem and, being a linux newbie, I did some research. The problem isn't just the memory. It's also slow because many parts of a "newer" linux distro are compiled for 686 (Pentium III and higher) processors. This means your older 586 (Pentium) has to do more work. It can really eat into your window manager and X windows server. At any rate, it made my box (PII 350mhz) unusable and I opted for an upgraded box rather than recompile everything and troubleshoot.

      Again, I'm a newbie and I'

  • This can mean two things... (Score:5, Interesting)

    by SharpFang ( 651121 ) on Saturday January 31, 2004 @09:37PM (#8147741) Homepage Journal
    Maybe one of them, maybe both...

    1) The new kernel is really very good.

    2) The old kernel is really very bad.

    Really, if such huge increase was possible, there must have been a lot of room for it. If you face a really well written program, you have a hard time to speed it up by 5%. If you can speed it up by 50% without loss in other domains, it must have been seriously flawed.

    Yeah, mod me flamebait. But first think if I'm really wrong.

    • Re:This can mean two things... (Score:4, Insightful)

      by natmsincome.com ( 528791 ) <adinobro@gmail.com> on Saturday January 31, 2004 @10:51PM (#8148143) Homepage
      Most of it has to do with the algorithms. For example I can write a really optimized bubble search but if you write an un optimized quick sort it will still be faster than my optimized bubble search. That being said any newbie programmer can do a bubble search but you have to know what you're doing to do a quick/merge sort.

      So while 2.4 wasn't using the best solutions it was better than nothing. It's always better to have bad working code than great code that doesn't work. Hurd is a great example. It may be batter but it doesn't work (well enough for me anyway) yet so who cares.

      IDE is another example. If I remember correctly 2.2 didn't have DMA support but it worked adding DMA makes it much faster but it would have made it more unstable if they added it at the beginning.

      The last thing that you have to remember is that lots of the changes were taking advantage of features in the newer hardware. If you ran the same test on 486 you wouldn't get the same results as you'd have different bottlenecks. In another 10 years we'll get the same thing again. The might make it so that the bus to the memory is as faster as the level 2 cache on the CPU. If they do that they'll have to make big changes to the OS to get rid of the new bottle necks and you'd increase the speed by another 50% or maybe even 100%

      Anyway that's enough ranting.

    • The root of all evil (Score:4, Interesting)

      by clasher ( 2351 ) <bkeffer@@@thecommandline...org> on Saturday January 31, 2004 @11:46PM (#8148471) Homepage
      Donald Knuth said "Premature optimization is the root of all evil"

      Therefore I assume #1 is much more likely than #2.

      It would seem as though the 2.4 focussed on getting a number of feature in the kernel while the 2.6 series allowed the developers to work towards making those new feature faster. Programming a new feature from scratch while also aiming to optimize it for speed can often lead to buggy code. Optimized code is rarely as straightforward and easy to debug as a more general (but slower) algorithm. When it comes to something as important as a kernel I'd much rather have clean, clear code which can later be optimized than a confusing kludge meant to squeeze out the last little bit of processing power.

      Just my humble opinion

    • Re:This can mean two things... (Score:4, Insightful)

      by be-fan ( 61476 ) on Saturday January 31, 2004 @11:54PM (#8148513)
      A kernel is much more complex than a single program. A program usually does one thing, and once you've optimized that, that's all there really is. In contrast, a kernel does all sorts of things. 2.2 was good for small-scale servers. 2.4 was good for mid-range servers. 2.6 is good for larger servers and desktop machines. 2.8 is supposed to get improvements to make it better on desktops and on huge NUMA machines. Linux has always been a fast kernel for what it did, its just that its doing a lot more today than it did a few years ago.

    • Re:This can mean two things... (Score:5, Insightful)

      by iabervon ( 1971 ) on Sunday February 01, 2004 @12:24AM (#8148650) Homepage Journal
      The old kernel had a lot of room for improvement on the systems they tested; but that's primarily due to the fact that the systems are substantially newer than the 2.4 series. A 2 GB dual Xeon system running 2.4 isn't going to use the processors efficiently (hyperthreading, imprecise locks), and isn't going to deal with the memory effectively. It was in part to take advantage of the availablity of such systems that the changes for 2.6 were made.

      New conditions require new optimizations and new designs; a good program optimized for a set of inputs which are common at one time may be really inefficient at handling inputs that become common later. Sure, you can make a program that's good for both sorts of input, but it doesn't make sense to try to do so until someone actually has such an input to test with.

  • Naked eye test (Score:5, Interesting)

    by Zordas ( 596510 ) on Saturday January 31, 2004 @09:38PM (#8147747)
    Yesterday I started a new Gentoo install with the 2.6.1 kernel. I used GCC 3.3.2 and glibc 2.3.2 with NPTL support. I have to admit, the naked eye can see a major diferance with the new kernel. With my XP computer and the new gentoo install (exact same computers .. P4 512MB) I ran a simple boot up and lanch a web browser test. And supprise supprise, Gnome is screamming fast. I had already booted and opened up mozilla 1.6 befor xp was even done booting! Also, simple stuff like opening up email, browsing, etc. is all noticable faster than XP. Soo... before I get slammed by the XP folks.. my XP box was also a clean install. (yes, I have no life!) I am happy to say I am one step closer to completely weening myself off of windows XP.

  • ahem... (Score:5, Funny)

    by Apreche ( 239272 ) on Saturday January 31, 2004 @09:42PM (#8147760) Homepage Journal
    2.4 is the old and busted
    2.6 is the new hotness

  • How does this compare to the BSDs? (Score:4, Interesting)

    by FFFish ( 7567 ) on Saturday January 31, 2004 @10:12PM (#8147902) Homepage
    THIS IS NOT AN INVITATION TO A FLAME WAR.

    Does anyone have factual comparisons of a reasonably-tweaked Linux (2.6 kernel) with a reasonably-tweaked [x]BSD (whatever kernel)?

  • Singing to the Choir. (Score:4, Insightful)

    by tealover ( 187148 ) on Saturday January 31, 2004 @10:16PM (#8147925)
    I wonder what the response would be if someone posted similar numbers about Microsoft's next OS. I'm sure they'd find creative ways to diminish the results.

    One thing I've learned is not to take tech writers too seriously. Most of them are writers for a reason.

  • It may be faster (Score:3, Funny)

    by Molina the Bofh ( 99621 ) on Saturday January 31, 2004 @11:50PM (#8148491) Homepage
    It may be faster, it may be smoother, but I bet it still won't be able to handle the full power of the terrible hordes of slashdotters.

  • Requirements? (Score:3)

    by chunkwhite86 ( 593696 ) on Saturday January 31, 2004 @11:57PM (#8148529)
    Does anyone know the Linux system requirements for 2.6? I.e. what gcc, libc, etc. are required to run it?

  • from the bang-bang dept. (Score:3, Funny)

    by HalliS ( 668627 ) <haralds @ h i . is> on Sunday February 01, 2004 @04:48AM (#8149706) Homepage
    This is what the 2.4. kernel had to say about this:

    Bang bang it shot me down
    Bang bang I hit the ground
    Bang bang that awful sound
    Bang bang my brother shot me down

    I was 2.4 and he was 2.6
    We rode on horses made of sticks
    He wore black and I wore white
    He could always win the fight
    ...

    Yeah, I know it's pretty crappy, but it's past my bedtime and I'm tired ^_^

Slashdot Top Deals

You will have many recoverable tape errors.

Close