NetBSD 2.0 vs FreeBSD 5.3 Benchmarks
diegocgteleline.es writes "According to OSnews, Gregory McGarry benchmarked NetBSD 2.0 against FreeBSD 5.3 and found that NetBSD 2.0 surpasses FreeBSD 5.3 in most of benchmarks. The machine used for benchmarks is a 3 Ghz P4 so it doesn't reflect the improvements of FreeBSD 5.3 in the SMP arena, which is where their developers have put their efforts in the last years and where NetBSD is still using a "big-lock" model. Newsforge is also carrying a interview with some NetBSD developers about the technology behind NetBSD 2.0."
FreeBSD's focus is typically on overall throughput of massive server, with responsetime as a tradeoff, while this benchmark with all of its timings of single OS operations is more something realtimish?
If NetBSD aspires to be a RT focussed distro/OS, they'd better have benchmarked it against some Linux with RT patches?
As an OS junky, I have used both of these BSDs, and am very impressed with them. I use FreeBSD on my P4 3GHz laptop, as Project Evil lets me use the WiFi card nicely, and ACPI kind of works. I use NetBSD on my Sparc Station 5 and my Athlon desktop, and I have found both to be wonderful for desktop use and as servers. I salute both of the groups of people who make these OSes, and wish that I had more time to contribute.
I would assume that FreeBSD has a "default install" as tested that supports at least 2-way SMP, given the focus that has been made in FreeBSD. This compared with NetBSD could make a huge difference, is NetBSD's default install also setup for SMP. It is a known fact that using an SMP compiled kernel on pretty much ANY OS will result in slower performance on a single processor, as the added overhead of locking data structrues will have to occur.
It is important to note that all of the tests that were performed where done on a uni-processor workstation.
The blanket statement that "NetBSD 2.0 has better threading and process management and network latency than FreeBSD 5.3" does not hold water when the test suite is run on 2 and 4-way SMP systems. FreeBSD 5.x is an amazing engineering effort in which various parts of the kernel have been locked down and decent thread concurancy can occur on multi-proc machines. Part of the latency that you see in these benchmarks are due to the mtx_lock() and mtx_unlock() overhead that is incurred.
It is also important to note that P4-systems with HyperThreading (As the one used in these tests) have been the "bastard child" on FreeBSD. For the longest of times, compiling anything with CPUTYPE=p4 would produce broken code (In all fairness, this was mostly due to a set of bugs in GCC 3.x). Significant work was put into 5.3 to ensure that the Pentium 4 lived up to the Tier-1 platform robustness standard. In short, it would be fun to see these benchmarks be run on i386/pentium3, i386/Athlon-MP, amd64/opteron and Alpha as well!
In the freebsd mailing list there was a troll using this test to come down on a couple of highly skilled developers. /. folks to enjoy:
;-)
Being lazy by nature I copy/paste my respone in the mailing list for the
Benchmark are made to be put into perspective, although everybody has a right to say what (s)he wants to say, this doesn't mean that you have to say it.
It seems to me that FreeBSD is focusing it performance onto MP 64bit processors. As we can see in the benchmark it has in comparison to other projects a negative impact on UP system.
But just put it in the perspective of processor developments, AMD (followed by Intel) is heading towards a multi-core 64 bit systems, what probably becomes mainstream at the end of next year.
With this technology the FreeBSD model could have a winner on there hands.
Doing the same job but not having the same philosophy on it, is always inefficient, but in the real world it leads to the Darwin effect.
What means that the best solution gets there chance of survival against the test of time.
Luckily these are all BSD's, good solution will spread, just take a look at PF.
OpenBSD has a good user base but not compatible to the sum of user base of the other BSD's. Still PF has spread there wings beyond the user base of OpenBSD.
FreeBSD is just a name for an OS, if any other OS can give me more "bang for the buck" and provides a full solution, I will use it.
Be it DragonFly/Free/Open/Net, MacOsX, GNU+Linux, Windows or any of the other hundreds of OS'es out there.
I like the BSD license so I will tend to stick to "gratis" BSD OS'es.
All of the disagreements in development is a healthy process to make sure the sort "BSD" an not the specie *BSD will survive.
Sure I have my disappointments about some decision, but hey so is live, this ain't a fan club for next biggest boy band (he he BSD-Boyz), where using an OS to provide solution for our technologic problems, you favor your solution but don't blind yourself.
And when you don't blind yourself you re-evaluate your situation and move forward with the best solution for your problem.
Sure it is a pain to migrate my boxes to another OS (well that is the fun part) and do some massive rewriting of my documentation, but thats my job and I tend to like it. Just standing still and not progress has its attractiveness when you had a very rough ride, but it gets dull very soon and then you find yourself back on the dirty tracks.
But these are my opinion only, however I like to share them
>why is there a need to post it multiple times?
d =11252088, as that person has the same opinion as me.
To dispel the FUD that those troll messages are continuously spreading.
Example: Microsoft makes a false claim about Linux (i.e. "Linux has a higher TCO", that generally is completely false). Do the Linux advocates react thinking "Oh, who cares, everybody knows it's not true. There are websites and common sense to disprove it" or do they react *dispelling* the *FUD* ?
FUD works, unless it's dispelled. I think everybody knows that very well.
>Read http://bsd.slashdot.org/comments.pl?sid=134840&ci
That person is right to say that a repetitive message shouldn't reach the +1 threshold - that's quite agreeable, and that's why I immediately complied with his request.
But he's simply wrong when he says that dispelling the FUD is useless, or that equates to feeding the trolls. If you guess the ones who modded that up agree with him, I guess the one that modded me up *multiple times* agree with me.
Your being very polite takes nothing from the fact that labelling that post as troll is completely unjustifiable.
I am not trying to sling shit on OpenBSD here, I've been using it as my primary desktop, net connected servers and firewall OS for very many years and will continue to do so. However I had to do something new recently that caused me to switch to NetBSD 2.0 for this project due to massive performance gains that could not be ignored (this may be due to my scripts being far from optimum at the moment, but)...
I have been doing some intensive data mining on some large datasets (500MB - 1GB) on a 2GB RAM PC.
OpenBSD 3.6 was taking days to do what NetBSD 2.0 was doing in under an hour and it appears to have mostly come down to NetBSD's disk caching. Multi passes at the large files show the disk access light come on just once on NetBSD and then the analysis flies. After seeing OpenBSD 3.6 performing so much slower with this task, I tried Fedora Core 3 and found it to also perform very much slower than NetBSD. In both cases, disk light is hard-on for the very slow duration of the task (which I did not finish for the Fedora machine because it was quickly apparent that it was also very slow).
Both BSD installs had noatime, softdeps and same partitioning for the filesystems being thrashed. I'd be curious to see if the gap closes much when I switch this over to perl. Disk performance even for single pass time trials in NetBSD are better than OpenBSD.
From now on, NetBSD will be my number cruncher. I am really shocked. I expected a difference, but not such a huge difference.
I thought Fedora Core with a 2.6 Linux kernel and disk caching would have kept up or perhaps even been better. Any config tips for that? I'd like to give SuSE 9.2 a go too... Regardless, NetBSD has really won me at the moment for disk intensive tasks.