Slashdot Mirror
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.
no.
in freebsd (I know this for a fact, I've gotton burned by it before) - if you compile a kernel for SMP, its NOT like linux in that it will fallback to UNIprocessing. it does NOT fallback! it hangs!
when moving an SMP custom compiled kernel to a non-smp box, you MUST rebuild the kernel or boot from an alternate non-smp kernel.
that sucks - but that's how it is. at least it is when I move a p6-built kernel from my dual xeon box to my single k8 box. both DO accept p6 as the ARCH type but the SMP code just causes a lockup upon boot.
(been running freebsd at home and at work for about 3 yrs now; and linux for about 10)
fyi
--
"It is now safe to switch off your computer."
I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of "glue that binds" FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone's throat.
The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain "unless someone is willing to pay for my time" (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past.
Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically).
If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively _cares_ about).
You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid "glee club" that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few o
on freebsd 4.x (at least) I can say this isn't true. you enable these 2 for smp:but it might be the apic option that causes the lockup. doesn't matter since both are required and both=on means an single cpu system will crash on bootup with this kernel.
--
"It is now safe to switch off your computer."
>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.
Hyperthreading is *NOT* SMP! It is a single CPU that can only do the work of a single CPU. It pretends to be two CPUs but it is not. If you were talking about multiple core CPUs, then you would be right, but p4 HTT processors are single core.
Treating HTT at SMP is, to quote from the FreeBSD Handbook, "naive". Intel agrees, though they don't use that word. Here's a quote from the article you mentionL "but further performance gains can be realized by specifically tuning software for Hyper-Threading Technology." In other words, you tune software for HTT *differently* than you do for SMP.
Don't blame me, I didn't vote for either of them!
Except that FGL isn't supported still on a good amount of hardware. Things as ubiquitous as a at keyboard, and last time I checked, the realtek 8139 network device give you the nice [GIANT LOCKED] message in dmesg.
If you have blessed hardware, you get better SMP support.
I will say that FreeBSD 5.x is better than 4.x in some areas (background fsck, smp on supported hardware, better threading support), however, as a total system, it's really not finished, and shouldn't have been released in its current state. Maybe Matt Dillon was right -- I don't know. But what they've put out isn't up-to-par quality-wise, when you compare it to 4.x.
NetBSD, on the other hand, really has come a long way with the 2.0 release. I would say that it's a better choice on i386 now than either FreeBSD 4 (which is deprecated, although there will be a 4.11 release), or FreeBSD 5. That they've gotten to that point is really a testiment to the amazing design work they do. It's a very good system that doesn't get enough attention.
- NetBSD (fastest)
- OpenBSD (happy medium)
- FreeBSD (slowest)
Of course, by this time next year the rankings might change, as all of these operating systems are still under development.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.