FreeBSD bind performance in FreeBSD 7

Ted Mittelstaedt tedm at toybox.placo.com
Fri Feb 29 07:45:38 UTC 2008



> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Sam Leffler
> Sent: Wednesday, February 27, 2008 8:54 AM
> To: Ted Mittelstaedt
> Cc: freebsd-performance at freebsd.org; Kris Kennaway; Oliver Herold;
> freebsd-questions at freebsd.org
> Subject: Re: FreeBSD bind performance in FreeBSD 7
>
>
> Ted Mittelstaedt wrote:
> >
> >> -----Original Message-----
> >> From: owner-freebsd-questions at freebsd.org
> >> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Kris Kennaway
> >> Sent: Monday, February 25, 2008 12:18 PM
> >> To: Oliver Herold; freebsd-questions at freebsd.org;
> >> freebsd-performance at freebsd.org
> >> Subject: Re: FreeBSD bind performance in FreeBSD 7
> >>
> >>
> >> Oliver Herold wrote:
> >>
> >>> Hi,
> >>>
> >>> I saw this bind benchmarks just some minutes ago,
> >>>
> >>> http://new.isc.org/proj/dnsperf/OStest.html
> >>>
> >>> is this true for FreeBSD 7 (current state: RELENG_7/7.0R) too? Or is
> >>> this something verified only for the state of development
> back in August
> >>> 2007?
> >>>
> >> I have been trying to replicate this.  ISC have kindly given me access
> >> to their test data but I am seeing Linux performing much slower than
> >> FreeBSD with the same ISC workload.
> >>
> >>
> >
> > Kris,
> >
> >   Every couple years we go through this with ISC.  They come out with
> > a new version of BIND then claim that nothing other than Linux can
> > run it well.  I've seen this nonsense before and it's tiresome.
> >
> > Incidentally, the query tool they used, queryperf, has been changed
> > to dnsperf.  Someone needs to look at that port -
> /usr/ports/dns/dnsperf -
> > as it has a build depend of bind9 - well bind 9.3.4 is part of
> 6.3-RELEASE
> > and I was rather irked when I ran the dnsperf port maker and the
> > maker stupidly began the process of downloading and building the
> > same version of BIND that I was already running on my server.
> >
> >
> >> * I am trying to understand what is different about the ISC
> >> configuration but have not yet found the cause.
> >>
> >
> > It's called "Anti-FreeBSD bias".  You won't find anything.
> >
> >
> >> e.g. NSD
> >> (ports/dns/nsd) is a much faster and more scalable DNS server than BIND
> >> (because it is better optimized for the smaller set of features it
> >> supports).
> >>
> >>
> >
> > When you make remarks like that it's no wonder ISC is in the business
> > of slamming FreeBSD.  People used to make the same claims about djbdns
> > but I noticed over the last few years they don't seem to be doing
> > that anymore.
> >
> > If nsd is so much better than yank bind out of the base FreeBSD and
> > replace it with nsd.  Of course that will make more work for me
> > when I regen our nameservers here since nsd will be the first thing
> > on the "rm" list.
> >
>
> Please save your rhetoric for some other forum.  The ISC folks have been
> working with us to understand what's going on.

Did anyone try disabling the onboard NIC and put in an Intel
Pro/1000 in the PCI express slot in the server and retest with
both Linux and FreeBSD?  As I run Proliants for a living,
this stuck out to me like a sore thumb.  The onboard NIC
in the systems they used for the testbed is just shit.  Hell,
just about anything Broadcom makes is shit.  They even managed
to screw up the 3c905 ASIC when 3com switched to using them
as the supplier (from Lucent)( - I've watched those card versions
panic Linux systems and drop massive packets in FreeBSD,
when the Lucent-made chipped cards worked fine.

> I'm not aware of any
> anit-FreeBSD slams going on; mostly uninformed comments.
>

It's customary in the industry before publishing rather unflattering
results to call in the team in charge of the unflattering
product and give them a chance to verify that the tester
really knew what they were doing.

FreeBSD has got slammed a number of times in the past by
testers who didn't do this.  In fact as I recall the impetus
for fixing the
extended greater than 16MB memory test was due to a
slam in a trade rag from a tester who didn't bother
recompiling the FreeBSD kernel to recognize the complete
amount of ram in the server, and running it up against Linux.

Maybe I am wrong and the ISC team did in fact call you guys
in before publishing the results - but the wording of
the entire site (not just the test results) indicated
they did their testing and informed FreeBSD after the fact.
after publishing.  Not nice.

Ted



More information about the freebsd-performance mailing list