Slashdot Mirror
Benchmarks of *BSD, Linux, and Solaris at LinuxTag
AnonymousCow writes "At LinuxTag, an unbiased comparison of performance of FreeBSD, NetBSD, OpenBSD, Linux, and Solaris." I'll let Tim's comment on this story stand: "Unbiased is hard to claim - all tests can be seen as biased in their formulation - but this is thorough, with 45 slides and
well-explained methodology -- BSD does very well ..."
Solaris is a long way removed from BSD. Saying Solaris is a form of BSD is just plain wrong at this point. And as for the odds being "stacked against" Linux, oh, come on, quit whining. Consider the case of I/O performance for instance. Here, the kernel's interface to drivers, and the drivers themselves play a large role. Linux has a single I/O lock, system wide, which all I/O operations must obtain before I/O is permitted. So _all_ I/O is _single threaded_. That's bad. It's kind of an architectural change to fix this, but it's being worked, or at least the infrastructure for a fix looks like it's being put in place...(the drivers will have to change to take advantage of it of course). In the meantime, expect to be routinely beaten by other OSes on I/O performance. Linux is a good OS, but, there are definitely areas where improvements could be made, and this is one of them.
You open sourcers are all alike. You apply one piece of logic to one aspect of a problem and then turn aound and be hypocrites about something else. Just look at Napster. You can do anything you want with other people's licensed music. Oh but don't touch my GPL'd code or I'll sick ESR and RMS and Bruce Perens and all the rest of the Goddamn Whiners on you.
I agree, good stuff.
I use Linux myself at home, just because I wanted a "free" OS, it was there (a friend offered a CD copy of RedHat 5.0 to me), the challenges of learning something new always are fun for me, and due to the price of NT (starving college student) I figured, why not? It suits me (now at RedHat 6.2) *shrug* I am also learning *BSD's / *NIX's as well for a number of college courses (2 OS courses of differing complexity, one networking/data communications class, and programming theory), and later work experience. I like "mucking about under the hood" when it comes to an OS. I eventually will revisit M$, Novell, Mac OS's (fingers crossed that X meets the expectations of Apple fans/users) and BeOS, dependent upon the needs of my future employers.
However, I think Bob DeNiro put it best in "Ronin". I'm paraphrasing here, but I think it was to the point of "It's a tool, that's all; you have some tools in a box, you use the right tool for the job."
If you have a favorite "tool", by all means, use it (heh, I'm talking technology you freaks), but be open to the fact that sometimes you have to use other methods to be successful and to make your employer, boss, customer, or clients happy. Be proficent in the use of other methods. Just my $0.02hermit "I could have been The Walrus, but I'd still have to bum rides off people." --Ferris Bueller
BTW, nice sig Argyle BTW, kidBSD does nothing for the open source community but drag it down. it is an inferior product, not as time tested as linux and full of coders who steal linux innovation and try to pass it off as their own.
its time open source be made linux only so the real work and innovation can be done without hinderance.
Linux, the choice of a GNU generation
The code is better.
There is real fragment support.
The kernel -> user space movement is superior.
It'll be better on a uniprocessor machine, and once BSD/OS's smp has been integrated into FreeBSD, it'll be better there.
User tests (mine) show the FreeBSD mouse pad to be far superior to the Red Hat product. The FreeBSD pad has a far smoother feel to it with the mouse gliding effortlessly over the surface. Red Hat's offering has a less appealing surface texture which grabs a little at the mouse. Micro-benchmarks indicate the Red Hat pad to offer faster overall mouse velocity however in end user tests the FreeBSD pad performs far better. The struture and color of the FreeBSD pad is more vibrant than the Red Hat pad which uses only three colors (red, black, white). The structure of the FreeBSD pad is also more organized with a firm support base and multilayer overlay. The Red hat base is thicker. The test platform employed was a standard office desk. A "Microsoft Intellimouse with Intelleye" to eliminate any chance of ball friction (funny how a software company makes better hardware than they do software).
WWJD? JWRTFM!!!
WWJD? JWRTFM!!!
WWJD? JWRTFM!!!
Really, then please tell me what the three servers I've been playing with today are. Well, okay, they're not quite that big, after all they're basically FTP servers to carry away the data generated by the big machine. (little ones: 1 PIII/800, 1G of RAM, 2 RAID-1 arrays. big one: 14 Ultrasparcs with 8MB cache for each, 14 gigs of ram, and a whompingly large RAID array on fibre channel).
Big machines do exist, and are quite common among the set of people who keep their load averages over 1, and don't run seti or dnetc. After all, am I supposed to tell my company 'yeah, I know we've got a couple hundred million bucks in the bank, but I really think we should run the mission critical apps on cheap PC hardware'.
----------------------------
Lots of people are saying Linux didn't have DMA turned on, and that's the reason for the low scores. You can see on Slide 41 that hdparm is mentioned with the -d flag. I think that means that he turned it on, ladies and gentleman.
----------------------------
I imagine, with DMA turned on (as it is by default, of course, with FreeBSD), Linux would've looked much better in these tests (and probably most of the others too since they all involve disk transfers to some degree.)
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
This obviously would've affected Linux's showing in nearly every test.
Maybe they should re-do this thing. And get rid of the horrid jpeg slides.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
This would kill performance in nearly every test.
The hard disk appears to max out at around 9MB/second in BSD but only around 4 in Linux, which is odd because it's been proven in other places that EXT2fs is at least a little bit faster than the BSD filesystem (even with async turned on).
Maybe they should redo these tests?
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
small update: some updates about the bad io results of linux will follow after more tests with different ide drivers (which
might be the reason for the extreme difference)
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Unless, of course, your heavy IO involves NFS, HTTP, or parallel compiles. Or did you just look at the first two slides and rush back to post?
I know this was a test of limited scope, but other than a home web server, who runs a "real" server on one processor and an IDE drive? I would be much more interested in a test using a plain adaptec 2940UW with a fast disk (10k rpm) and at least two processors.
Solaris is not aimed at uniprocessor/IDE machines. That hardware setup should be reserved for a test of workstation benchmarks. A test of "real" servers should include more than one client and much higher loads than the machines were subjected to. After all, can you consider it a "real server" if there's only one client doing read/writes?
Warning: I am a Sun employee. I try to keep my biases in check, but I am only human.
_damnit_
_damnit_
It's my job to freeze you. -- Logan's Run
% uname
/lib/libc-2.1.3.so /lib/libc-2.1.3.so
/lib/libc-2.1.3.so
Linux
% ls -l
-rwxr-xr-x 1 root root 888596 May 1 20:26
% file
/lib/libc-2.1.3.so: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/mill
The vast majority of NFS is done over UDP, not
TCP. TCP stack idiosyncrasies/incompatibilities
would not affect the results.
-Chris
Use an unstable branch then?
Yes, apparently. The Quakes run just as well on FreeBSD as they do on Linux.
> FreeBSD... The choice of those, who know how to choose...
You sound like a few wine snobs I know.
FreeBSD may have it's technical merits, but I know plenty of people who run it just for the "fringe appeal". These are the people that ran Slackware way back because it seperated them from the crowd.
After the Red Hat IPO, Linux officially arrived and was no longer properly counter-culture. Once big money was involved, Linux became establishment, and that's just not chic. Then the people who ran Linux just to be different had to look for a new system -- luckily for them, the BSD's provide an easy migration. (yes, I know that BSD dates back to before Linux)
I feel some of this effect myself. I confess that part of why I use Debian is to seperate myself from the kids who purchased a RH boxed set at CompUSA, clicked their way through an install and now proudly play Solitaire in Gnome.
In the old days it *did* mean something to hack together a functional system from the disk sets that Slack provided, or that you downloaded by hand. There was a base level of proficiency that was necessary even to become a Linux user. This exclusion is rapidly breaking down in the Linux world, but lives on in the BSD world.
I'm not sure that any of the BSD's want to lower the entry barrier. Arguments of elitism aside, lowering the barrier definately lowers the mean competence of your user base, and I think that's something FreeBSD and the others would rather live without.
It seems to me that a lot of the *BSD users on Slashdot just wait around for good news about their system so that they can triumphantly reveal how superior their tastes are. It gets a little old.
FreeBSD... Because Linux just isn't leet enough anymore.
--Lenny
DMA is part of the protected mode disk drivers, along with 32-bit operations.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I guess Roblimo was right.
Some people in the design business say the best way to learn what the WWW will look like in six months is to keep up with Jeff [Zeldman]'s famous www.zeldman.com site.
Or are all these BSD guys color blind?
What I'm listening to now on Pandora...
Someone correct me if I am wrong, but compiling has alot more to do with the compiler, libs, headers then the actual operating system. I am guessing that linux has alot larger/more libs and headers to take into consideration when compiling an application then either solaris or *bsd. Second I think NFS was a bad choice in testing network performence, NFS is unique to the OS, and as such it is testing the OS specific implmetnation of NFS more so then the OS (Not to mention Linux is WELL KNOWN to have crappy NFS). Samba would of been much more useful in benching the operating systems ability. The IO difference between freebsd and the other operating systems looks rather like what I see with UDMA disabled :) I get better performence marks on a pentium 200 with UDMA enabled (under linux). I would agree that this benchmark isn't biased, it's just poorly done.
-- You can be a geeklord too
Have you not heard of package management? You know, dependency resolution, etc.?
--
Fuck the system? Nah, you might catch something.
There is no such thing as a $500 Sparc, unless you are using an old Sparc 5/10, circa 1995.
That is one of the best things about this comparison: it's in crappy hardware. I am sick to death of these useless 4CPU, 4G of RAM, 12 disk RAID array tests that just have no bearing on reality. Give me $500 of intel crap, load it with pr0n, and see which one the 'net kills first. THAT would be a test!
I don't think RedHat's 'fancy-looking-ness' should be mistaken for ease of use. The user friendliness of FreeBSD is the reason why I use it at home. The config tool sysinstall actually works, the BSD package manager actually works, all unlike the bits RedHat added to linux. /usr/local.. etc. All package information goes under /var/db/pkg, so files don't get lost, and the uninstall tool actually works. My guess is it works well, because FreeBSD is being developed and maintained as an entire OS. Linux is a kernel, and the usability really depends on what a certain distro company wanted to add.
It also annoyed me no end, what a mess RedHat makes of the directory tree, with separate library directories, binary directories etc for every package, which requires you to keep long lists of environment variables set (QTDIR=.., KDEDIR=.. etc).
BSD just keeps the libraries in the libraries dir, binaries in the binaries dir, packages not part of the OS go under
The one thing were Linux is easier on the user, is make xconfig, whereas BSD requires you to edit a textfile, but I don't think Redhat had a lot to do with that tool, or did they? I know I should really try a different Linux distribution, to give it a fair chance, but since I haven't needed it yet, I haven't gotten around to it yet. One thing is for sure: it won't be RedHat.
Reiserfs looks promising, I'll probably use linux for that fileserver I'm setting up.
I agree, and in addition to that, the Solaris x86 CDs perform exceptionally well as beer-mats.
Actually, the sysinstall is a nice, menu driven program. It's just not graphical, which means it will also work without X and Gnome. Packages can be installed via the ports (this will mean compiling, except in the case where the ports are only available in binary format, like netscape), or as binaries with pkg_add.
It would be a very good idea if you read some docs on XFree86 configuration... you can physically damage your monitor and your videocard if it's done wrong by the configuration program, as appears to have been the case with you. The autogenerated XF86Config file looks intimidating, but most of it you don't need at all. In the case of XF86-4.0 it's been made a bit easier too.
Sure, for servers that's good, but I want bleeding edge. It's just more fun and interesting.
Plus, need I say much more than "Quake"?
Send your friends messages of love at fuck-you.org
I actually like BSD. I was just being a snot. (bored at work today. Don't often get the chance to be bored, so, I thought I'd do some trolling)
Send your friends messages of love at fuck-you.org
Am I going blind or are all those graphs damned near impossible to read? They were done in JPEG format which is sub-optimal for graphs and text. I found it almost impossible to correlate the legend with the data points. It sure would be nice to see them in PNG format.
Well said. I think all of the *nix'es have their specialties. I use Linux on my laptop, FreeBSD on my desktop and web servers, and OpenBSD on my firewall.
I will say this, though. New Linux users need to be very careful in their choice of distributions. You'll find that the security, performance, and reliability does vary from Linux distribution to distribution.
I think you should be more cautious in your cheerleading. 2.4 has potential, but the realization of that potential is diffcult and not gauranteed.
IIRC, bonnie uses the stock getc() and putc(), which under Linux are threadsafe. These functions acquire a lock in userspace, and so have more overhead than is necessary for a single-threaded application. As Doug Ledford explains on this page, bonnie performs much more realistically when modified to use the non-threadsafe versions (which is a valid thing to do in a single-threaded application).
--Joe--
Program Intellivision!
It's called Nightmare File System for a reason you know. =)
Catch many with that der' pole?
F /...
Whats up with trolls these days being so blatently obvious. You trolls need to goto some creative writing classes or something... hell spend some time on USENET. It can only help.
---
Solaris/FreeBSD/Openstep/NeXTSTEP/Linux/ultrix/OS
--- I do not moderate.
The patterns in the disk read performance figures look suspiciously like the sort of gaps you get with and without DMA enabled on a disk. I note that the motherboard is a VIA board; Linux is known for having problems with DMA on via boards. Also, depending on distro, some may or may not enable DMA by default on bootup.
My opinion is that the BSDs having in the range of (say) 10% improvement over competitors would be easily explained by possibly better file system and VM architecture. But when we see a difference of five to one surely there's got to be something seriously wrong there. I've gotten better bonnie figures than that on an old Pentium.
Can anyone explain why NFS performs better on Linux with a Linux client and better on FreeBSD with a FreeBSD client?
in any case, we should take these tests with a large grain of salt. there are MANY factors unaccounted for: driver quality for the hardware used on each OS, IDE settings (hdparm on Linux), choice of filesystem, sync/async mounts, softupdates or not on BSD, journaling or not, and the large can of worms that is kernel tuning (did they do any?).
at least there are a few things we can tell kind of reliably from these tests: 1) the BSDs and Linux are all great; Solaris/x86 is generally slower (but may have better SMP, which wasn't tested here), 2) Linux 2.4 is a real improvement over 2.2, and 3) nfs and network stuff is faster when the client and the server use the same OS flavor.
This is the second time I've seen this comment of 2x. It's a crock of shit:
% uname
Linux
% ls -l
-rwxr-xr-x 1 root root 4118299 Sep 20 1999
% uname
FreeBSD
% ls -l
-r--r--r-- 1 root wheel 537268 Jun 12 00:26
Looks closer to 10x to me...
hdparm doesn't enable/disable DMA itself, that requires kernel support for the chipset. It will set the mode for types of DMA transfers, and can disable DMA. Using hdparm on a kernel which doesn't have DMA support will not do anything to the DMA characteristics of the drive.
I agree with the above comment. The filesystem performance differences should be at WORST a magnitude of 100-200 % worse/better in either case. BSD by default enables DMA, (for detected/supported chipsets, in my experience), while linux tends to require specific support for the udma transfers (recompiled UDMA patched kernel, my experience). Also, the hdparm -unmask option for servicing other interrupts greatly improves the overall responsiveness and feel of the system (in X, once again, my experience).
It doesn't appear these tuning parameters were applied, so I would expect any linux i/o bound results do be dog slow relative to any of the other OS's. The solaris results are so similar to the linux results for prolly the same reason... SCSI would have been a better test for this one benchmark.
--Adrian
One nitpick (and I have FreeBSD 4.0-Current on one machine and Debian potato on another so don't say I'm biased) but the BSD libc does *not* have all the same functionality as glibc (at least, not that I could find). Some examples are argz vectors and obstacks (neither are really necessary, but they exist in glibc and not BSD libc, i know, i was planning on using both and needed to rewrite the functionality for FreeBSD cause it wasn't in the libc).
The BSD's are a great system, but the ports tree isn't all it's cracked up to be (it NEEDS an upgrade procedure, I'm sorry but apt-get is the best package method out there). Fix the ports tree and SMP (I don't care if Linux's is sloppy, it works today) and get support for bleeding edge graphics cards (I like being able to play my video games too =) and I'll switch completely.
(No this isn't a flame, just honest criticism from someone who uses both on a daily basis, and both as workstations, not servers).
You're right, the ports collection is nice, but it NEEDS a good upgrade system. Uninstalling something like the gnome just takes too long and I've yet to get everything uninstalled properly to do an upgrade. apt-get is my current favorite for installs/upgrades. As easy as ports, but it can upgrade everything too.
and here's our crappy Powerpoint display... Ick! I'm not sure if I should run out and install the Brownish redline with triangle or the Blueish grey line with diamond! Someone tell me which is best? Man whats with the techie Yuropieons and their lack of color matching skills? Would someone please write an open source version of the RBG color spectrum so the rest of the nonCOLORBLIND WORLD could read stuff like this!
when they ban enctryption only criminals wi$21*J *#JF$%!@#$':
Oddly enough, with 2.4.0-test4 I'm seeing the opposite, a 60% disk performance increase, much better than 2.4..
Geoff
What's the deal with these damn slides! They suck ! What's wrong with just posting the results as a simple text file or plain old HTML????
the I/O performance varies from development kernel to development kernel and they're still tracking issues down (ie, someone reports 200% improvement on one kernel, but says it's worse in another.. really amazing actually).
What this means is that the Linux developers are playing with black magic and don't really know the effects of their performance tuning. Each dev kernel is a "hmm, does this fix the problem? or what about this fix?".
cpeterso
Solaris really performs on sparc.
And it's not designed for 'serving pages'. THat is a computationally light task.
Try a real server, serving many users on interactive X sessions at once, all with wierd simulation packages running. Solaris reigns.
Cheerleading? Perhaps you should check the latest Spec99 results. Quite impressive, disk I/O suckage notwithstanding.
Actually, as I understand it from following the LKML, the I/O performance varies from development kernel to development kernel and they're still tracking issues down (ie, someone reports 200% improvement on one kernel, but says it's worse in another.. really amazing actually).
> The *BSD's perform better under heavy I/O.
I'm not so sure this is the case had they compared against 2.4 rather than 2.2. But, the goal was to compare against production kernels, so it was a fair test I guess.
2.4 does scale WAY WAY better than 2.2, though.
Well, If you will read at the bottom of my post, DMA is turned on for the numbers I posted. The numbers would have been much closer, but I was playing MP3's at the time. They're is still a 1.5 second difference today with no MP3's playing.
Could be something wierdwith this PC, but that's the straight scoop from here.
Obviously, people didn't read the tests very carefully.
Solaris had big numbers for the SQL tests. Unfortunately, those were in seconds -- so Solaris actually did very POORLY on the SQL tests.
Please, everyone, read carefully. There's some good info on those slides but it is not clearly presented.
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
It looks like they used Solaris x86, which is not as finely tuned as Solaris/SPARC. It would be intersting to see what Solaris on SPARC could do against linux, assuming they both had similar hardward cost constraints.
Also, I thought an IDE hard drive an odd choice for a high performance server test - wouldn't SCSI or RAID be more appropriate?
Who am I? Subscribe and find out
How can solaris suck at everything if it poststed the best postgresql scores?
Don't forget that the main reason Sun maintains x86 port is to get students, geeks, developers, etc interested in their Solaris platform. As far as Solaris production systems are concerned, most of them are Solaris on ultrasparc.
Also the later versions of the OS really need more RAM to operate efficiently. 64MB? This is a joke for Solaris. I bet there would be a -significant- performance increase if they used ~128MB.
IDE drives, another joke. Solaris IDE drivers never were good (look even at the ultrasparc based Ultra5/10 with IDE disks). On intel they gotta be worse by definition.
Why is this topic was posted in BSD cathegory?
*BSD weren't the only systems featured in the test and in addition while they performed well, they didn't beat the other OSes in all tests, just in some of them.
Why?
well, am bored, and i stopped working for a while.
* The *BSD's have just become the latest thing you show you are knowleadgeable, just like linux was a few years back...
Well, i don't wish to change anyones preference.. You use the best or the job... and on many tasks... But that doesn't change the gfact, that FreeBSD is still a better engineered system.... again... face the facts.. i mean... damn kernel httpd? ok, give me a break, maybe on a micro kernel arch, but on a monolithic? maybe am wrong... hehWHile this could be true, i personally don't think so. Most New FreeBSD users can be categorized into two main sectors. One, ex linux users, that want to try it out, and see what is all about. Mostly because of problems they've had with linux, other times because they just want to try something new.Two, current Solaris,commecial unix users, that are looking for a reliable platform, on relative inexpensive hardware.
If you're somehow wondering my background, my first unix experience was on solaris, back in 1993. FreeBSD in early '96. Linux, debian, in mid '97. My preference... isn't it odvious?
* 2.4 will close any gaps in heavy I/O FreeBSD may have an advantage in
EHHHHH, nope. At least not in my testing or anyone's testing... 2.4 is slower on many things than 2.2 is.
* SMP is better on Linux
One comment... the difference between doing it right, and doing it slopy is a great one my friend.
* Linux dev is Free'er than the BSD's
In linux kernel dev, you are subjected to the views of two main controlling forces... Linus and Alan... FreeBSD... about 15 core team members, with greatly equal vote.. plus the rest of the commiters.. plsu everything is available right away on CVS, unlike the linux kernel... AGAIN BRANCHES MY FRIEND...
FreBSD just follows a more mature approached to developement... I advise you to read up on it.. Linux is still the hobbyist OS that it started as.. and hopefully that will change.
Don't believe about the code quality? well, the BSD C lib is half the size of the GNU lib C, with the same functionality..
scrap that last paragraph,, i think i omitted a line or two... :P
It shows what linux groupies always try to deny...
The *BSD's perform better under heavy I/O.
Unlike the general linux mentality of, get it out the door if it barely works, the BSD mentality has alwasy been... it only goes out, if it's ready, and mature enough to go out... Hence the different release branches...
FreeBSD... The choice of those, who know how to choose...
Flame filters... ON... you can flame all you want, but you cannot change the facts.
NFS can run entierly over UDP or TCP and that is a CHOICE that is made at mount time - either automagically (as Solaris can do - not sure about others) or manually by the person typing the mount command.
NFS never uses a combination of UDP and TCP for a particular mounted filesystem. It is possible to have multiple filesystems some being accessed over UDP and some over TCP but not using both protocols for the same mount point.
Simple clear graphs, easy to understand pages.
This would have been a good talk to attend.
nuclear iraq bioweapon encryption cocaine korea terrorist
Nicely put. I would add that the results seem to be skewed in favour of matching client and server OS in the NFS and HTTP tests - compare "NFS char read Linux client" (img18.htm) with "NFS char read FreeBSD client". This probably reflects that the developers prefer test rigs with their OS doing the client piece. It's interesting to see that it makes such a large difference.
ROTFL.
:-)
*ahem* Sorry. Um, how can I say this? You're wrong.
(Incidentally, I would expect your device not configured message to be caused by not having Berkeley Packet Filter compiled into your kernel)
Unless you're just a troll, in which case you might want to aim for a little more subtlety next time, maybe.
Have a nice day now...
>NEEDS an upgrade procedure
Hmm? cvsup you mean?
I've never seen rpm give a description of a package while I'm installing it. Granted, rpm has a switch that'll describe a given RPM for you, but pkg_info on FreeBSD can do the same.
FreeBSD has to resort to Linux binary "emulation" to carry out some tasks, like run Netscape. I didn't try it out, but the idea just doesn't feel quite comfortable. Call me prejudiced.
No, it doesn't. Only if you want to run Linux binaries (for when you can't get source, like commercial programs). You don't have to use the Linux Netscape. It runs better under the Linux ABI Compat (it's not really emulation) than the native FreeBSD Netscape does, but that's because Netscape won't build an ELF binary. Another alternative is to run the BSD/OS Netscape, since that's ELF and doesn't require the Linux compat.
And yes, your fears regarding Linux compat are completely unfounded & driven only by prejudice. :) It truly is a remarkable thing.
FreeBSD 4.0 ships with Gnome 1.0, which is obsolete. I hope I can compile Gnome 1.2 with it (will try today after work).
And RedHat 6.0 shipped with an obsolete GNOME too. So? 4.0 was -RELEASED 6 months ago, give it a break. If you update your Ports Collection, you can install the latest Helix GNOME 1.2. I just did.
I don't see how your points lead to the conclusion that Linux is better for the desktop.
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
pkg_info will tell you what you need regarding all installed Ports (and Packages too, which are really just precompiled Ports ala 'make package'.) Since I've not used Debian (you should have said Debian, not "Linux") I'm not really sure what you're referring to regarding browsing.
Yes, and I don't use RedHat 6.0 (I use Mandrake 7.1).
This was kinda my point. If you use something old, it's going to include old software. If you use something new, it's not.
Upgrading my Ports collection is not an option for me, because of the lack of net access (I use my box mostly for programming & toying around, instead of net-related stuff).
That's your fault, not FreeBSD's. Still, you should be able to compile GNOME 1.2 well enough on your own. You may need to refer to the current related Ports (there's 10 or 15 or something like that. Normally a meta-port takes care of the dependancies, though I usually install them each manually so it doesn't go installing bits of GNOME I don't care for or use [like games].) Just browse to www.freebsd.org/ports on a net-connected computer and take a look at the patches and configure options they use. Or don't and hope Miguel and company write with Systems-Other-Than-Linux in mind.
I think being able to start programs quickly is quite essential for a desktop system
And your example was that huge bloated monster of a program that thinks it's an OS in and of itself, Emacs. Oooookay. :)
Perhaps it was built with different compile-time options. If you're used to an emacs binary Package on Linux, was it optimized for your processor type? Did you install it on FreeBSD as a Package? (Packages are not compiled with any optimization.) Or did you install via Ports and not set optimization flags in /etc/make.conf? Whatever the case may be, there's a bit more to consider here than just the OS.
, and this is my main problem with FreeBSD (I read from a PDF linked to from this thread that mentioned FreeBSD having inferior fork & exec performance when compared to Linux). OTOH, I've only used it for, what, 4 hours, so perhaps I might change my mind after prolonged use (and after R'ing TFM).
Yes, 4 hours is too soon a time to develop "problems" with an OS. Any perceived problems during the learning curve can usually be attributed to ignorance, which can be fixed, as you said, with a little of TFM.
Hop on over to Undernet's #FreeBSD and if I'm not busy (I IRC from work, but I'm not always watching) I'll help out where I can.
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
If you're not net connected, then how will you get GNOME 1.2's source onto the machine? You can get a new Ports Collection on it the same magical way, as well as the required distfiles (what the Ports Collection calls the source tarballs, which you were planning on getting anyway.) Just make sure you get the right tarballs.
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
Ahem, I think OS's should not require net access for almost-full functionality.
I agree. You have everything you need. Old versions of third party software isn't non-functional, it's just old, and to be expected when you're using a -RELEASE that's also 6 months old.
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
If you ever have to do high-speed packet capture, the packet filter (BPF) in the BSD stack is far superior to the Linux one (even the latest kernels, where packet capture has been improved).
It took me awhile, but I finally managed to get a mirror of the site up. Hopefully this should ease the Slashdot effect. It will be up unless the author asks me to remove it.
The URL is http://www.dynamine .net/mirrors/innominate.org/projects/tuning/
The server is on a 100Mb Exodus link, running FreeBSD 4.0. Have fun!
I'm with this guy on the DMA issue, bu I also noticed that they never set the IDE drive to use 32 bit access.
Consult your kernel source. 32-bit I/O support flag (-c) is used only for PIO modes.
When you use DMA (-d), then DMA controller does the data transfers (AKA "bus mastering"), and CPU does not need to tranfer data at all (be it in 16-bit or 32-bit mode).
Repeat your tests with DMA turned ON and you'll see no difference at all.
So the benchmark says that Linux isn't up to par. We don't have to believe it, but we for sure shouldn't play the game of blaming it on some secret organization out to make Linux look bad; payouts, free CDs, etc.
I look at it this way, if there is any truth to these test, we should jump on it. We shouldn't sit around typing on a computer talking about the flaws in their benchmark. We should be sitting on our asses trying to scan the code find where we can improve it. Hell if your not a great programmer, try it anyway, perhaps your self estimation of your abilities were greatly underestimated. You never know...
I am a Linux User, don't plan to change. But I give BSD its props. Linux will be at your heels soon enough!!!!
Peace...Stop the madness
I don't know what life is, but no one gets out alive...N
eh? the current version of linux is 6.2? freebsd 5.0 is comparible to linux 2.3? sounds like someone else who has fallen into the "redhat=linux" myth, yet is also confused in other ways too. Geeze...how long has it been since redhat 2.3? was there ever one? (lol) I know I used to use slack 2.3...(shrug) current version of REDHAT is at 6.2. Current "version" of Linux (stable) is 2.2.16
This is completely untrue. FreeBSD is under the BSDL, it can never be like that. There will be a merging of BSDI-NDA code eventually, the SMP code is something FreeBSD users are looking forward to.
this space for rent
This is completely wrong. Solairs is based on Sys V first of all, SunOS had BSD roots but solaris is a completely different beast.
The BSD's are not the same OS. FreeBSD, NetBSD and OpenBSD are not BSD distros they are 3 operating systems with the same ancestor.
Is there a difference? Yes a big one. PErforamnce is not the same on all of them, they do not all support SMP, the security model is different to some degree on each of them. Please research before you make these comments.
this space for rent
the scale in the sql test was time needed. so the bigest bar for solaris there means that it was slowest....
I think one could attribute this to network stack idiosyncracies. For example, if the Linux stack only sets its recv buffer to some specific size that's smaller than the *BSD size, would account for the difference. IIRC, Van Jacobson pointed out a number of problems with the TCP implementation doing weird things in slow start and congestion avoidance that might also account for impedance mismatching.
A similar problem cropped up when Samba was benchmarked against NT's SMB implementation.
-scooter
Solaris x86 is a dog, so while it's admirable that he tried to include a commercial Unix, it's really too bad he couldn't run it on proper hardware. I would have liked to have seen any areas where BSD and Linux beat Solaris, on Sun hardware.
You're reading the compile time graphs upside down - lower is better for compile time. NetBSD was the best, Linux 2.2 was the worst on that test.
Of course all the slides are in German, so I'll have to get them translated to read more into the tests.
Sorry, I just read the first bit of the slides and assumed that they were all in German (based on a previous post). I guess that makes an ass of me. The slides are actually in English and very clear and well laid out.
This is definately one of the better trolls I've come across. It is a bit too heavy handed at the end with the feeding poor children thing, and mentioning Microsoft directly just yells 'Troll!'. I thought it worked better for the first two paragraphs.
Kinda funny too, since Gore's and Bush's financial policies aren't at all the different.
Unfortunately, since it seems to have no connection to the article, it looks like another SPAM troll, though the first instance of it that I've come across.
Come on, can't you at least releventise it for the current discussion, a little, please?
Looks like I'll be installing some flavor of BSD on my spare machine. Last time I tried Linux, it was just so unorganized and non-standard (yes, yes, I know LSB, but still...). I'm hoping the BSDs are a bit more tame as far as organization and standardization. I would even take whatever performance hits there were with NetBSD if it is actually written and designed elegantly enough that someone as rusty as me in C and C++ might actually be able to tinker with it (I am assuming most Linux users don't even dare putzing directly with their kernel). I wish there were some force for convergence instead of divergence as far as Linux distributions are concerned. Maybe that LDPS will help. It just seems that nothing really has enough teeth to tame the wildly fragmenting Linux distributions (how about a single package standard, a single update standard, even compliance with LSB?). I don't know, maybe I'm just talking out my ass.
It's 10 PM. Do you know if you're un-American?
I think testing such as this is helpful in other ways as well. For one, I'm sure the testing was open, so true to any real research it can be duplicated and dissected by others. This is healthy and leads to improvements in the weak points of all the systems, the open ones anyway.
Also, the open systems ship with the code, or at least have it available. Strong points in the leaders can be looked at to find what it is they're doing right. I wouldn't advocate stealing the code outright without attribution, but more efficient ways of doing a particular thing can find their way into the weak links in any of these open systems, improving them all.
Finally, a little competitiveness between Linux and *BSD advocates keeps everybody sharp. I don't see a problem here.
There is a very thorough benchmark comparing Linux (kernel 2.2.12) to
FreeBSD (4.0). The benchmark takes time to analyse file system
performance, kernel timings such as contexts switches and use of
memeory managers and thread/process creation, all tied up with an
excellent summary.
The problem is that most systems ship with DMA off. It causes problems in some configurations, and is usually a liability for the vendor.
A deep unwavering belief is a sure sign you're missing something...
This compared to the Linux crowd whose benchmarks are, "oh, I just installed this and have only used Windows before and Linux is the fastest thing I've ever seen," or "on my 386 33 with 4 MB of RAM, Linux absolutely BLOWS AWAY Windows 2000" or my favorite "I've been using Linux ever since kernel .9 and its so fast! I mean, I played around with the Win2K alpha release, and Linux is SO much faster. What WM am I using? I don't run X, what a silly question! What do you MEAN that my comparison is invalid?"
A deep unwavering belief is a sure sign you're missing something...
Actually, over the years, MaximumPC's editors have suggested all manners of ways to punish vendors who ship with DMA off. I think one involved a ferret and a wet noodle...
A deep unwavering belief is a sure sign you're missing something...
It seems to me from the HD benchbarks, that the *BSD's are running the IDE drives in DMA Mode, and that it is not enabled by default in the linux kernel, so performance does suck. That supports the myth of SCSI being faster than IDE ..
--
Samba Information HQ
But I guess I didn't use the proper submission form, so oh well :)
-bugg
Have Softupdates enabled? It'll create an increase in performance that's definetly noticable.
-bugg
Many Linux dists ship libc*.so with debugging symbols in them. That doesn't affect the in-core memory requirements.
It is irritating however, when you have to upgrade to the latest libc RPM you have to download huge files.
AC, you're obviously very upset over something. Clearly you seem to know what you're talking about, and it seems you have done a good deal of research on this subject, so let me ask you something: WHY is karma SOOOOOO valuable?! It ain't to make your trolls show up on those who browse at +2 or anything, is it? I mean is that really that important? I browse at -1 all the time just because I think the random "I sucked your mom's dick last night" inserted here and there is absurd and therefore amusing.
Anyway, what I'm really trying to ask is - what difference does it make whether someone is a "karma whore?" And how does someone become a karma whore anyway? No one's going to mod you up unless you have something interesting to say!
Confused,
~'Kruzr
+++ATH0
Fear...
It would be nice to have some unbiased moderators now.
Oh and btw, in the one slide it even shows that hdparm was tweaked for all those who just refuse to believe that Linux lost. Sit on it potsy.
Yes, but then you would be testing 2 different OSs on 2 completely different architectures (x86 and SPARC). Unless of course you mean we should test Linux/SPARC against Solaris/SPARC - but that would probably give the advantage to Sun, considering that Linux/SPARC is probably far less optimized than Linux/x86 (the inverse is true for Solaris).
I'm actually interested; in my own personal experience, BSD's TCP/IP stack has been unremarkable.
Sadly most people don't / can't think like that. IT seems that at least the vocal users *must* have 'their' OS be the best. Linux users in particular insist that Linux be not only the equivalent of a decathalete but a decathalete that also wins the gold medal in every individual event.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
Read again people!
http://innominate.org/%7Etgr/slides/performance
They did use linux 2.4.0-test1-acxx as it says; "very fresh kernel due to the big problems in the vm [blah blah] in the late 2.3.xx kernels, also linux 2.2 was tested
OK, not trying to start a flamewar here (though I think that for this story, that may be an impossiblity). But was anyone really expecting *BSD to just roll over and die in the face of Linux? BSD has one badass TCP/IP stack, and it can't be much of a suprise that it did well. Keep in mind, readers and moderators, that I mostly use Linux. I'm not trying to be a BSD evangelist. I feel that FreeBSD 4s user-friendlyness is fairly low comared to, say, RH 6.2. But OTOH the *BSDs, especially FreeBSD, seem to really try and make their networking fast as hell (and the succeed).
Simliarly, the fact that Solaris cleaned up in the SQL test shouldn't be suprising.
BTW, some of those graphs were really hard to read, but in some didn't 2.2 wildly outperform 2.4? Specifically Seite 34, parellel compiling, real time. I'm confused!
> [and both Linux and FreeBSD use glibc.]
No, FreeBSD does *NOT* use glibc.
All *BSDs use their own libc.
NFS server writing:
http serving:
Postgresql:
Parallel computing (task switching):
Solaris:
Pretty devastating stuff. Nothing I haven't been saying for years though.
Beware of people who don't understand relece sceduls. This is also offtopic and flame bait. Where is a good moderator when you need one.
If you have ever tryed to run x86 on a p150 with 32m you would not be so suprised, cheep hardware is not suns forte.
Once again, atack my spelling not my content! You dipshit! Oh did I spell that corectly??
I could be wrong, but I thought BSD was through with legal issue with AT&T well before Linux became popular. Unless you mean the advertising clause, which was dropped more recently.
I do honestly think the copyleft aspect does have more to do with it. BSDs from all I can find are quite capable, competent systems. But *BSD is Free for now (yes, what's released can't be taken back, which is good, but anyone can close derived works with impunity, which bothers some of us,) GPL is Free forever, and that does seem to attract more developers and let Linux move forward a lot quicker.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
For the Intell Enviroment I think Solaris was a poor choice for a comerical UNIX. Because Solaris was developed for Sparc Systems, And on Sparc Systems Solaris runs Very well. But the Intel version isn't to optimized for the Intel/PC Arcetecture. Sience Solaris for Intell isn't optimesed for Super Performance. I think for a comerical Unix they shoud use SCO or some other Unix designed for the Intel Enviroment for the test.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
thats why there is meta-moderation, if you are modded down unfairly than you will get moderated up when meta-moderation steps in , and the guy that moderated you down unfairly will get - points in karma.
-- http://electronicintifada.net --
They used solaris x86 instead of the "real" solaris running on sparc processors.
It's like >80% common code. The SPARC chips just give you associative cache, hardware contexts, 144/288 bit ECC memory paths, etc... Solaris x86 is "real"... It's the x86 hardware that's a joke.
BSD people have an odd obsession with their inferiority complex.
Conversely... Linux bigots have a strange superiority complex....
But seriously... BSD should run rings around both Linux and Solaris. At least until they have to start managing structure locks and kernel access. Then they'll be where Linux was four years ago... Or Solaris back in 1992.
Now on a 4-way or larger multiprocessor box... Solaris is going to kick serious butt. It's at that point that the overhead from the thread management starts really paying off. Sadly, this is also the point at which the x86 hardware usually folds.
Temkin
Yeah, I know... But I was feeling particularly self-rightous last night, and I felt like venting. So I engaged in some troll-flame therapy. Just as long as he/she doesn't send me a bill... :-)
Temkin
The FreeBSD facility to do all that fancy stuff is ipfw (IPFIREWALL). Ipfw support also has to be compiled into the kernel. Alternatively you could try to load the repective kernel module.
Man ipfw for more information sorry, wrong. bpf is not related to any of these, and supposed to give you raw access to network data.
br> f.
Bzzzt. K6-400 is a super socket 7 cpu, requiring same chipset. the VIA chipset is NOT an Apollo Pro chipset, its an MVP3 (or mvp4 hybrid).
Write your Own Operating System [FAQ]!
no sig for you
Pay attention. In the related links box it's .com. Unless you have those boxes turned off that is. VA's gotta get somethin' for their money.
I'm always wary when I see a test such as this that says "let's keep the hardware the same and compare just the software". There's a very dangerous illusion of equality which is just a fantasy.
Linux may have better disk access -- for IDE drives. But if FreeBSD handles SCSI better, is it fair to conclude that Linux is the better OS simply because you only used IDE drives in your comparison?
The reality is that you can't compare OSes in any meaningful sort of way and generalize the results to say "X is better than Y". To be scientific about it, you have to say "X is better at Y, only if run on <this_platform>, and then only at doing <this_task>, etc..."
And to be fair, the guy who did this study, pretty much said as much. His tests are basically valid for anybody with a stock K6-450 PC wanting to run a free Unix(like) system and possibly a web server.
Somehow, this gets transmogrified into "thorough" and "unbiased". =) Not that I'm disputing the results, I run FreeBSD myself. I just think it's important to take a step back and look at the whole picture.
--
Tommy
*BSD sucks? Really? Then why are Yahoo! and Hotmail using FreeBSD and not Linux? You should avoid blanket comments like that -- they really make you look like a retard.
If you knew anything about Unix, you'd know that proper coding of a Unix application will allow it to be compiled on any Unix system. Linux users, usually too proud and haughty to acknowledge anything else, write lots of software that doesn't compile anywhere else. BSD users, when writing software, are more attuned to the topic of portability, and write code that compiles everywhere, including Linux. Example: Python. Guido uses FreeBSD -- not Linux.
I run Linux on my two personal computers, a hacked up old Redhat dist and a newer Debian (potato) dist. While I like Linux a lot, both distributions caused a great hassle in terms of getting things neat and clean. Too many packages wallowing around with configuration files scattered. I understand Debian is trying to work on this (and there's always slackware...) but I have found that FreeBSD's layout is very clean and simple and when you are setting up a server you do not want lots of junk cluttering up your disk space and possibly posing a security hazard. OTOH, I installed XF86 on the Linux boxes (4.0.1 on the redhat :) and that has a tendency to waste disk space, cause security problems, and clutter up directories; I generally do not install X on FreeBSD boxes. Oh well :) :)
In any case, my main point is that the BSD's tend to be much more cleanly packaged (and NetBSD has cleaner code..), whatever the kernel's performance is like. There is probably a Linux distribution out there that tries to focus on remaining clutter-free, but with all the many distributions out there it is often hard to see the smaller ones. Not to imply having many distributions is a bad thing, choice is always good. But when you have to setup multiple servers, inanities can drive you nuts.
OTOH, I created a two-floppy IP Masq (or NAT, whatever;) firewall off of Linux 2.2.14, to run on a 486-DX50, 8 MB RAM, with no harddrive. With 10BaseT ISA cards, it managed to pass 400k/s while performing as a IP Masq firewall. Not too shabby, running FreeBSD on that (and probably the others) would take a lot more effort, if it were even possible. But it did take an awful amount of time to get going... (tip: hack slackware bootdisks instead of trying to create your own from scratch
It boils down to a matter of personal choice I suppose. I use both, like both, and I get along just fine.
Those who do not know the past are doomed to reimplement it, poorly.
Testing? What's that? If it compiles, it is good, if it boots up, it is perfect.
-- Linus Torvalds
This has to be my favorite argument with linux tcp/ip
http://www.spatula.net/proc/linux/localhost.src
With the linux development process the users are the alpha/beta testers.
Only the State obtains its revenue by coercion. - Murray Rothbard
I was kinda suprised at the benchmarks of Solaris, I kinda expected more. It doesnt really suprise me that linux kicked its can at most things but figured it would be right in there most of the other OS's
And if you look carefully, you can see some typos and colloquial errors that you would not expect a native english speaker to make, not to mention german punctuation habits. Still, it's a lot better than babelfish, so I admire the effort. That english is better than I could do the other way around.
WARNING: there is a trojan on your
It's still handled by the VIA82CXXX driver, so these parameters still *need* to be set to get UDMA working.
It seems that the test system was a K6-400 with a VIA ide chipset. It was probably an Apollo Pro, which isn't very well supported by Linux at the moment. Examining the filesystem performance graphs shows around 3 MB/s throughput, which is exactly what I was getting out of my Apollo before I got UDMA working with it. You have to apply the IDE patches to 2.2 to even have it available, though it's in the 2.4-test series. You need to enable support for VIA82CXXX, ATA Works in Progress, Use PCI DMA by default when available, and VIA82CXXX Tuning support (a work in progress). After doing these things, I get 22 MB/s (!) out of my IBM, and 19 MB/s out of my Western Digital. If the Linux kernels had been compiled with these options, the results of the tests would have been quite different, I'd say.
[snip]
It's important to remember that FreeBSD's support of Linux applications is not an emulation in the classic sense but rather an ABI implementation
As things stand today {Net,Free,Open}BSD seem much more stable and useful for their intended purposes than Java (and we haven't suffered a tenth of the hype produced by the Javaniks).
It wouldn't be the end of the world if native ports were never released.
Yes, you are a retard. BSD is kicking your feeble Linux operating systems ass in the benchmarks. Linux is for bedwetting pussies. Enjoy.
Wow, I guess I'd better spread the word amongs all my peers in the BSD community. Here we are, still developing software on for a system that is dead. Shoot. If it weren't for your insightful comments, I may have just continued to use BSD. Darn, it's a shame that it is dead. What exactly does it mean when software is dead anyhow? Should I bury all my install disks and stuff? Thanks for spreading your well educated opinion.
It sounds like your brain is what's dead. Try breathing more deeply to increase the flow of oxygen.
Of course, finding volunteers to run this "nonintrusive" profiler on their production machines might be hard! My point is, there may be very strong interactions between the various types of system calls that a simple benchmark will overlook. I'm sure something like this is in the literature, but if so, why hasn't it been used in academic circles?
It's not the first time I've seen a benchmark like this. Last year the UK magazine PCPlus did a comparative revue of a number of SCSI and EIDE interfaces (including an IDE RAID array). Windows biased, of course, with no comparative mention of other OS support.
They ended their review with a set of benchmarks. To me the faster ones didn't look too good. Then I read the comments next to the RAID controller's results, stating that the test had been done in compatability mode. Reading between the lines indicated that they did all their benchmarking under Windows 98 or even DOS, and as no DOS drivers were available for that RAID controller, they'd just accessed that one by the BIOS, and ran the remaining tests using a DOS application, which most likely used PIO. Fsckwits!
Then again I know of one major UK company that is rolling out 1000s of Windows 95 and NT PCs, all of them using the standard PIO IDE driver supplied with the OS, despite the fact that every machine is fitted with ATA-33 capable drives. Neither anyone in the IT department nor their hardware supplier (Compaq Certified!) seemed to be aware of the different IDE operational modes. Sad, very sad!
Even here at work very few of the NT workstations have UDMA IDE support installed. They're hiring a full-time sysadmin who should do these things, so I'll test him when he arrives.
I've yet to see a comparative benchmark where the person performing the tests know how to configure the hardware properly. The main philosophy seems to be 'Hey it works! I don't need to do any more with it!'.
It is true that FreeBSD Java support is lagging, even though java.sun.com lists a FreeBSD port as the most requested enhancement.
Be ot or bot ne ot, taht is the nestquoi.
Be ot or bot ne ot, taht is the nestquoi.
this comparison may be on some interest if it was performed on half decent hardware. I mean who whould use a k6 for a server?
Why didn't they include Windows NT or 2000? Aint they sposed to replace unix in the future?
Adam's Preliminary Page of BANG~!
Adam's Preliminary Page of BANG~!
http://www.ualberta.ca/~engel
solaris on a machine with 64MB of RAM. IDE. hmmm.
how 'bout those char reads? reading one char at a time with read? boy, i bet that's *fast*.
block size? how was that converted back to kb/s? i'm of the mind someone wasn't paying attention to their units. so to speak.
%ian
enefesdi bhootparamdi
if a thing is worth doing at all, it's worth doing right. -- H.S. Thompson
Their latest version, 5.0, is roughly comparable to Linux 2.3. Since the current version of Linux is 6.2, this is clearly unacceptable.
Ummm... the latest version of Linux is 2.2.16. Don't confuse Red Hat version numbers with the Linux version numbers.
Since I havent seen anything about LinuxTag, here are a few words:
...
It is supposed to be the largest Linux event in europe. It was held some time ago in Stuttgart, Germany. There was one "business day" with attendance fees. I havent been there but I heard it was booked out. Then there were three additional days free of charge for everyone. It consisted of a exhibition and lots of talks. I was there 2.5 days and could have spend more time there. The exhibition was very large, with all the major Linux players, plus a lot of large hw-manufacturers (HP, Siemens, SGI...), lots of publishers/book shops and lots of boothes for open source software/technologie, for ex a GIMP-booth, a VRML-booth etc.
There were almost 100 talks! These were the reason I went to Stuttgart.
The (in my mind) major talks I didn't hear were: Gimp (Simon Budig), VRML (Jörg Scheurich), Berlin, CORBA,Tcl, Tk, KOffice, KDE 2.0, Bonobo
The talks I heard were:
Kylix (Borland staff)
XFree 86 (Dirk Hohndel)
Dear Mr Brooks (Alan Cox)
Gnome (Matthias Warkus)
Keynote (RMS)
Blender (Carsten Wartmann)
Sourceforge (Tony Gunthorpe)
KDevelop (?).
BTW, the (english) link to LinuxTag is http://www.linuxtag.de/2000/english/
Slowlaris is supplied by Sun. Sun makes its money by selling very expensive hardware. Why is anyone surprised that slowlaris doesn't use hardware as efficiently?!?
I hope we aren't going to hear more of a third-party like Linuxtag fixing the benchmarks by being bribed with free cd's.
The hardware on this test is in no way indicative of what even a low-end server would be comprised of. Barring the perverbial refurbished 386 email server, I'd expect the minimum configuration to have SCSI harddrives, hoping even Ultra2 10K drives, and 256MB of RAM to be anywhere close to a real-world server. If you want to do a load test, make sure you're not locked in hardware bottlenecks.
Ryan Earl
Software Engineer
Ryan Earl
Software Engineer
There is a FreeBSD version of Netscape... And GNOME 1.2 (or KDE 2.0 beta, if you'd rather) will compile.
If violence isn't solving your problems, you're not using enough of it. - MAJ Misato Katsuragi
Incidentally, I installed FreeBSD 4.0 over my Linux 2.2.15 yesterday, just to see what all the fuss is about. My box is PII-266/64MB. I made some observations:
The conclusions seems to be that FreeBSD is better for servers and "utility" systems that need to remain simple, while Linux is better for desktop. I didn't try any networking stuff, for the simple reason that I don't have network access.
Save your wrists today - switch to Dvorak
Solaris had big numbers for the SQL tests. Unfortunately, those were in seconds -- so Solaris actually did very POORLY on the SQL tests.
Right you are--my apologies.
But I think what I initially said still holds; if it works for you, use it. Even Solaris isn't bad, after all--just "not as good" as some alternatives.
Questions of bias aside, I think this benchmark makes it pretty clear that there's no such thing as a absolute "best" system--even the author says as much in his conclusions. While the *BSDs performed very well for filesystem I/O, Linux did nicely in the HTTP tests and Solaris topped everyone in SQL performance.
Also, something the holy-war people seem to forget is that even the comparatively badly-performing systems are more than sufficient for the majority of users. How many people, for example, serve more than 10 dynamic pages per second?
I guess what it boils down to is use the one you like best. Linux, *BSD, Solaris, etc. all have things to recommend them, which all appeal to different people. I personally have the most experience with Linux--I was introduced to it first--so it's what I use daily, but I've had my eye on FreeBSD for a while as well. (No spare computer to put it on yet, though...)
And think of the irony of trying to tear down a Windows monopoly only to replace it with a {Linux,FreeBSD,...} one. Competition is good, and variety is the spice of life. (^:
Benchmarks are useless unless you have a replica of their configuration as various subsystem drivers have varying levels of maturity for each of the respective systems.
Are there people that see such an image/slide
presentation (powerpoint?) as anything
but a primative form of communication?
Isn't HTML a better format for documents than GIF?
1) the IO numbers look very suspect, Linux was always capable of saturating IO bandwidth up to 60MB/sec even on modest hardware. This is so basic that they should have stopped the test when they saw how far the block IO numbers are apart. It certainly does not show alot of experience in tuning Linux.
2) the 'per character' numbers of bonnie are utterly meaningless. Bonnie is not a smart benchmark tool, but it gets quoted often. The 'per char' numbers simply measure the performance of libc's "getc()" function [and both Linux and FreeBSD use glibc.]. So the effect of the 'per char' measurement only slows Bonnie down and skews the numbers with additional CPU time. In fact i use a hacked Bonnie that just does the 'block IO' numbers - looking at the 'char IO' numbers is a waste of time.
3) While i understand the deadline issues, the 2.4-ac series were seriously buggy. It's only 2.4.0-test5 that started behaving properly, VM and IO-wise.
4) Linux's name is 'Linux', not 'linux' - they got it right with 'FreeBSD', so it's not hard :-)
5) the apparent IO misconfiguration then reflects in all the 'high load' numbers, so all the slides (except maybe the network numbers) should be redone IMO.
Thomas Graichen
thomas.graichen@innominate.de
innominate AG
http://innominate.de
http://innominate.org/~tgr/projects/tuning
Overview
- Disclaimer
- Why?
- Which Systems?
- What To Test?
- Details
- Results
- Conclusions
- Other Issues
- Tuning
- Future
- Thanks
- Contact
Disclaimer- no OS religious wars please!
- keep it simple - nobody is perfect
- there will be no "winner"
- more complex than expected
- moving targets - everything may be different tomarrow
- depends on hardware, drivers etc.
- ment [sic] as a relative comparison
Why?- curiosity
- linux is more often used in the "classic" server area - how does it perform?
- in the shadow of linux some other free OS are more often used, too - how about their performance
- often comparisons are quite biased
- finding ways to tune a given system for more performance
Which Systems?- all currently available free OS which are usable for production: linux, FreeBSD, NetBSD, OpenBSD, Hurd
- Hurd did not seem to be suitable after some initial tests (1GB filesystem limit, nfs bugs, no posgresql)
- to get a feeling of how all this compares to "commercial" systems we also tested solaris/x86 (7&8)
What To Test?- filesystem performance
- nfs performance
- webserver performance
- database performance
- scalability (parallel compiling)
- most tests done also in parallel
- a lot more possible
Details- all tests were done on exactly the same hardware (K6/400, VIA, 64MB, 6GB IDE, 100MBit 3com)
- same hardware was used for client and server c/s tests
- disks were partitioned exactly the same way on all systems
- data partitions were freshly formatted
- all the services are configured as identical as possible on all systems
Details (cont.)- all tests were done on dedicated otherwise unloaded systems
- client server tests were done on a 100MBit back to back connection
- systems were carefully set up
- tests were run multiple times to make sure that they give reproduceable results
- client/server tests were run with two client systems: linux 2.2 & FreeBSD 4
Details - Systems- recent versions of all systems
- linux: 2.4.0-test1-acxx - very fresh kernel due to the big problems in the vm and buffer management in the late 2.3.xx kernels, also linux 2.2 was
- *BSD: checkout of the -CURRENT trees from spring this year (2000)
- solaris: version 7 and 8 for x86
- Hurd: not tested
Details - Filesystems/NFS- interest: filesystem throughput
- bonnie - measures transfer-rate of block- and char-wise sequential in- and output on file 2 x main memory
- for nfs: run on a nfs mounted directory
- other things possible but are not done: bonnie++, large amounts of metadata operations, performance on large directories, tests of various filesystems (reiserfs, gfs, xfs, jfs, lfs)
Details - Webserver- interest: http access performance
- http_load - can create well customizable load of random http accesses for a given url list
- 3 times parallel: 32 big file fetches (1MB), 1024 cgi fetches (hello), 4096 page fetches (1KB)
- multiple threads and instances in parallel (2, 16, 64)
Details - Database- interest: performance of sql queries
- postgresql as database target
- a few random value tables of various types loaded into it
- little mix of sql statements ran against it (selects, inserts, updates, joins, deletes,
...)
Details - Scalability- interest: scheduling, virtual memory management
- compilation of MesaLib-3.0
- increasing number of parallel compiles
- all with a little relative time to avoid all doing the same at the same time
- why Mesa ? - compiles on all platforms tested, no configure, big enough
Results- even these simple tests show: there are differences of performance between the systems for various tasks
- NetBSD and OpenBSD are quite close to each other (history)
- at least some of the free systems are in most of the tests better than the "commercial" UNIX solaris
- linux 2.2 has some serious problems under higher loads
Conclusions (cont.)- linux 2.4 will most probably bring linux in nearly all tests cases to the top level
- in some cases it is really advisable also to consider the others (esp. FreeBSD for high load, NFS and IO)
- performance is not all (OpenBSD - security, NetBSD - clean design, portability, solaris - applications)
- trying to compare as many systems is more complex than you expect
:-)
Other Issues- SMP scalability (locking problems)
- linux: 2.2 is ok, 2.4 is good
- FreeBSD: 4.0 is ok, SMP project
- NetBSD, OpenBSD: in progress
- solaris: good
- filesystem scheduling: linux 2.2 has problems with parallel bonnie - 2.4 better
- lots of filesystems to choose from: reiserfs, xfs, gfs, jfs, lfs
Other Issues (cont.)- mbuf problem: for all *BSD systems the NMBCLUSTERS parameter has to be raised for any serious use
- with full http_load the *BSD systems tend to produce errors - careful tuning required
- linux nfs implementation has serious problems (async, stale file handles, etc.)
Tuning- linux:
- /proc/sys/...
- hdparm (-d, -Xxx,
...) - kernel config
- FreeBSD, NetBSD, OpenBSD:
- sysctl kern, vm.
- kernel config
- solaris
- /etc/system, ndd
http://www.innominate- filesystem:
- which one
- blocksize, async, soft updates
- nfs:
- rsize, wsize, async, v3, tcp
- others:
- optimized recompilation
- optimized applications (apache)
- duplex network settings
Future- moving target: is only valid for today
- should be continued (time
... :-)
Thanks- I would like to thank all people at innominate who helped me with all this
... especially Jens Sanders and Michael Krax and innominate itself.
ContactThomas Graichen
thomas.graichen@innominate.de
innominate AG
http://innominate.de
slides:
http://innominate.de/~tgr/projects/tuning
the table of contents is in German?
I guess the Tag in LinuxTag had nothing to do with X or HT ML. Probably the German for day...<s>
Anyone else notice NFS performance for *BSD to to *BSD to be significantly faster than Linux to *BSD? Same goes for Linux to Linux. Hmm...
*/
(end comment) */ }
[an error occurred while processing this directive]
Maybe you can...
"..don't you eat that yellow snow."
Apparently it wasn't biased towards any ethnicity: the table of contents is in German? while the rest is in plain English.
"The 85 I fear they don't got a clue."
I don't understand why people produce shitty and irresponsible benchmarks OR why SLASHDOT would give this CRAP any attention. Several things are clear from this data. 1) Several of the system had there ide drives in MODE 4 at best. Not only is this PAINFULLY obvous from the test scores nobody in there right mind is going to put a piece of via shit in a production server let alone some door stop of an IDE drive. If SCSI drives had been used in the first place this would have even gotten around the shitty VIA chipset. 2) When the solaris boxes turn in the worst NFS scores alarm bells should be ringing (setting aside the fact x86 solaris is a bastard), HELLO remember sun... they invented this little thing called NFS. Disk I/O obvously was fucking things up and I'm sure that the solaris system tuning was non existant. May I remind you that many a consultant makes there living tuning solaris boxes and there are several books dedicated to the subject. 3) If the intent is to show scalability why was a uniprocessor system used? I'm typing this on a linux/sparc box but crap man do really think that every buisness in the world that uses solaris over linux/bsd is smoking crack? (well crack would explain NT's use but I'm side tracking). Solaris does have higher system requirements then bsd/linux due to overhead in things like the ip/stack but everything is fully threaded and will leave everyother platform in the dust (even on x86) when scaling to multiple processors.
It was totaly FUCKING STUPID to have even released these OBVOUSLY WRONG benchmarks. I hope that everyone see's it for the PISS that it is.