Slashdot Mirror

I have a Belkin F5D6050, and it works fine with the atmel driver from http://innominate.org/kurth/at76c503/ . I've also found linux native drivers for my laptop, so they're out there, it just a pain finding them. I would think one of the problems is, that the manufacturers don't bother writing linux drivers, because they count on FOSS people writing some for them, and users don't complain enough.

Other DNS software

Management tools

twa lets authorized browsers edit the tinydns data file.

ldap2dns converts an LDAP DNS database to a tinydns data file. tinyadmin is a graphical interface to the LDAP DNS database used by ldap2dns.

mkdns converts a MySQL DNS database to a tinydns data file. It lets authorized browsers edit the MySQL DNS database.

sql2tinydns is similar to mkdns.

dhcp_dns watches dhcpd for new DHCP address assignments, and publishes those addresses through tinydns.

tinydyndns publishes dynamic IP addresses authenticated through POP connections.

Servers

ldapdns publishes DNS information from an LDAP database.

MyDNS publishes DNS information from a MySQL database.

Posadis publishes DNS information from BIND-style zone files. Security history: Buffer overflow, allowing attackers around the Internet to take control of the server; fixed in m5pre2 (2002.03.30). Someone announced an exploitable buffer overflow in m5pre2 a few weeks later; the history here isn't clear from the Posadis web pages.

NSD publishes DNS information from BIND-style zone files. Security history: Unclear. The NSD documentation includes bugs like ``Very strange coredump in hash_destroy() that happens sometimes'' without any analysis of their security impact. Is that an exploitable buffer overflow?

PowerDNS publishes DNS information from MySQL databases, PostgreSQL databases, Oracle databases, IBM databases, LDAP databases, or BIND-style zone files. Security history: Unclear, like the NSD security history.

MaraDNS is a general-purpose DNS server.

lbnamed is a load-balancing DNS server.

lbdns is another load-balancing DNS server.

Oak DNS Server is a good example of why novices shouldn't try to write DNS software. The digitallumber.net domain, served by Oak DNS Server 1.0, is inaccessible to a huge number of clients that try AAAA lookups before A lookups: the server incorrectly returns NXDOMAIN for AAAA, effectively wiping out its own A record.

Caches

pdnsd is a DNS cache. Security history: Remotely exploitable buffer overflow; fixed in 1.1.7a (2002.01.18).

MaraDNS can act as a cache.

I don't know why anyone would want to use these caches in place of dnscache .

DNS clients

adns is a DNS client library.

ares is a DNS client library.

perldns is a DNS client library for Perl.

The Buggy Internet Name Daemon [how very professional... *sigh*]

BIND is a monolithic server/cache; it also includes a client library, libresolv. Security history: IQUERY buffer overflow in BIND before 8.1.2-T3B (1998); NXT buffer overflow in BIND before 8.2.2-P4 (1999); nslookupcompla

• dnsmasq - A DHCP+DNS server that is simple to configure, lets you set up names for local machines and local services, lets you block external names of your choice, etc, etc
• masqmail - A mail server for machines with intermittent connections to the internet (dialup, laptops, wireless)
• Xmail - A slightly bigger mail server for when you want to run your own domain. Linux and Windows.
• Icewm - The window manager for people who want to get their work done
• Bluefish - Text/HTML/Perl/PHP/Java/etc editor that just works.

Hi,

Did you miss the one application does one thing well paradigm?

>Pine can't hold my calendar and sync with my palm, and itegrate all that with my e-mail.

That's because Pine is an email program. It isn't a virtual operating system like Emacs, nor is it sucking at the teat of an operating system like Outlook.

If I want to backup my palm (which I just got for $39 CDN -- WOW), I'll soon be using coldsync because programs that do just one thing well make sense to me.

And, when I want to use a calendar, I'm certainly not going to use an email client. That'd be like going around the world by making bridges across the continents. I'll be using something like this.

When I need to syncronize my mail, I'll use this.

If I really want everyone scrunched into one application, I'll use this.

I haven't even scratched the surface of available applications yet...

You windows people amuse me.

In the future, you might want to search freshmeat before you assume windows does it best.

I remember reading on /. about another filesystem called tux2 .

The web site is here, but I don't really see anything giving a status update.

Anyone know anything about this project?

I felt obliged to point out that Daniel Phillips, of the Tux2 file system, has now created indexed searched through directories (similar conceptually to btrees, but not quite as fast).

Check out the mailing list archives here
For directories with over 20000 files, the results are 10 times faster with the indexed searching. The ratio gets better with more than that. So I guess ext2 won't have to wait long for btrees. If Tux2 happens sometime soon then it will really rock ! Great job Daniel !

There are *such* better projects than ext3 that are so much further along its rediculous to think that ext3 has any chance of becomming the next standard filesystem. Tux2 has a much more interesting technology that could allow really great stuff, such as journaling of meta and file data. It'll even be possible to use its phase tree algorithm to allow online fscks (useful to check for decaying filesystems). ReiserFS and XFS are also really great, but Tux2 and ext3 are the only ones that can convert ext2 automatically. Daniel Phillips who's working on Tux2 is also pumping all sorts of other nifty features into the patch, such as tail merging and a system that puts btree efficiency into the FS without the complexity of btrees. Its way beyond the competition. Further, it should be ready for the 2.5 tree, while ext3 has been in development for 2 years...

Your Study doesn't exist at all. Are you spreading Linux based FUD? Now here's a _real_ study from last year. Interesting, Linux get's blown out of the water in many tests and has a slight lead in static web pages.

It's also obvious according performance testing stuff of last year that FreeBSD way outperforms OpenBSD.

The only unix I run at home is an OpenBSD machine. I also have a single OpenBSD co-locate (personal server) at my work. Let me count the ways of the pain dealing with webserving on that thing.. PHP / MySQL problems, etc. It's not bad that because it's only a single machine, but if I had to run 50 of these things, I would switch to FreeBSD in a heart beat.

Actually, he meant

Slide 35

Slide 36

so you don't have to cut and paste the frigging URL from the article's text.

I also seem to remember some discussion of some IDE setting perhaps being more conservative on Linux than on BSD in an earlier Slashdot article about that benchmark.

In any case, please note that Slide 42 says:

moving target: is only valid for today

Sometimes benchmarking results get read as "release x.y of OS A did better than release z.w of OS B in this benchmark, so OS A is better than OS B" rather than as "...so release x.y of OS A may be better than release z.w of OS B for this particular type of task". The fact that release x.y of OS A did better than release z.w of OS B doesn't, in and of itself, demonstrate that OS A will always be better than OS B at that particular task (which should be borne in mind by fans of Linux, {Free,Net,Open}BSD, Windows NT (which includes W2K), Solaris, etc.). The OSes in question are "moving targets"....

Actually, he meant

Slide 35

Slide 36

so you don't have to cut and paste the frigging URL from the article's text.

I also seem to remember some discussion of some IDE setting perhaps being more conservative on Linux than on BSD in an earlier Slashdot article about that benchmark.

In any case, please note that Slide 42 says:

moving target: is only valid for today

Sometimes benchmarking results get read as "release x.y of OS A did better than release z.w of OS B in this benchmark, so OS A is better than OS B" rather than as "...so release x.y of OS A may be better than release z.w of OS B for this particular type of task". The fact that release x.y of OS A did better than release z.w of OS B doesn't, in and of itself, demonstrate that OS A will always be better than OS B at that particular task (which should be borne in mind by fans of Linux, {Free,Net,Open}BSD, Windows NT (which includes W2K), Solaris, etc.). The OSes in question are "moving targets"....

Actually, he meant

Slide 35

Slide 36

so you don't have to cut and paste the frigging URL from the article's text.

I also seem to remember some discussion of some IDE setting perhaps being more conservative on Linux than on BSD in an earlier Slashdot article about that benchmark.

In any case, please note that Slide 42 says:

moving target: is only valid for today

Sometimes benchmarking results get read as "release x.y of OS A did better than release z.w of OS B in this benchmark, so OS A is better than OS B" rather than as "...so release x.y of OS A may be better than release z.w of OS B for this particular type of task". The fact that release x.y of OS A did better than release z.w of OS B doesn't, in and of itself, demonstrate that OS A will always be better than OS B at that particular task (which should be borne in mind by fans of Linux, {Free,Net,Open}BSD, Windows NT (which includes W2K), Solaris, etc.). The OSes in question are "moving targets"....

Linus believes he is a 'CVS with taste'.

If that's not good enough for you, try here.
--

Appears to be this:

http://innominate.org/~phillips/tux2/

Two els

This was taken from Apache's own Performance Notes Site.

IIS may be faster. I actually don't know, because I've never used it. But I will say this: I worked at LinkExchange when we were the number one company in Internet reach (52%). That's right, more eyeballs than AOL, Yahoo, and MSN combined. And we did this using Apache; both for our site, and for our banner network.

Not to start a flame war, but there's also a chance that the performance bottleneck is Linux, and not Apache - LE was using FreeBSD. There's an excellent benchmark of various Unices, which may indicate as much. It well done, but doesn't get going until page 8 or so...

Anyways, be sure to take administrative costs and bandwith constraints before making a decision.

It is also proof that open source software does not just 'chase tail lights' - the work is substantially innovative.

Phillips is also implementing tailmerging (a feature from ReiserFS to efficiently store small files) for ext2/ext3/tux2.

For more details, check his web pages here, and the linux-fsdevel mailinglist.

I don't see why not. I used to run Red Hat on an Ultra Enterprise 4000 at work a while back. The E10K has a different internal architecture to the rest of the Sun Ultra Enterprise line, but the support's already there in the Linux kernel. See arch/sparc64/kernel/starfire.c.

This page also lets you get at some free IP, although you have to go to one of the subdirectories, download and unpack the tarball, and get it from the appropriate directory...

Here's that particular free IP in an easier-to-view form.

Nice judge and entier OS on one single incedent. BTW what hardware config are you running? And what ver of BSD? Just curious cuz every benchmark I have seen between Any BSD and redhat has shown BSD to average better. (I am not saying that this is true for Linux in general just redhat, although the resent artical on slashdot pointing to this shows the contrary)

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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

• #13 filesystem - char read
• #14 filesystem - block read
• #15 filesystem - rewrite
• #16 filesystem - char write
• #17 filesystem - block write
• #18 nfs - char read - linux client
• #19 nfs - block read - linux client
• #20 nfs - rewrite - linux client
• #21 nfs - char write - linux client
• #22 nfs - block write - linux client
• #23 nfs - char read - FreeBSD client
• #24 nfs - block read - FreeBSD client
• #25 nfs - rewrite - FreeBSD client
• #26 nfs - char write - FreeBSD client
• #27 nfs - block write - FreeBSD client
• #28 http - pages - linux client
• #29 http - pages - FreeBSD client
• #30 http - large files
• #31 http - cgi
• #32 sql - real time
• #33 parallel compiling - real time
• #34 parallel compiling - user time
• #35 parallel compiling - system time Conclusions

• 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

• 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 :-)

• 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

• 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.)

• linux:
  • /proc/sys/...
  • hdparm (-d, -Xxx, ...)
  • kernel config
• FreeBSD, NetBSD, OpenBSD:
  • sysctl kern, vm.
  • kernel config
• solaris
  • /etc/system, ndd

• filesystem:
  • which one
  • blocksize, async, soft updates
• nfs:
  • rsize, wsize, async, v3, tcp
• others:
  • optimized recompilation
  • optimized applications (apache)
  • duplex network settings

• moving target: is only valid for today
• should be continued (time ... :-)

• I would like to thank all people at innominate who helped me with all this ... especially Jens Sanders and Michael Krax and innominate itself.

• Disclaimer
• Why?
• Which Systems?
• What To Test?
• Details
• Results
• Conclusions
• Other Issues
• Tuning
• Future
• Thanks
• Contact

• 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

• 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

• 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)

• filesystem performance
• nfs performance
• webserver performance
• database performance
• scalability (parallel compiling)
• most tests done also in parallel
• a lot more possible

• 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

• 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

• 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

• 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)

• 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)

• 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, ...)

• 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