Re: FreeBSD bind performance in FreeBSD 7

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

mdtancsa
At 10:44 AM 2/29/2008, Chris wrote:

>A weakness of freebsd is its fussyness over hardware in particular
>network cards, time and time again I see posts here telling people to
>go out buying expensive intel pro 1000 cards just so they can use the
>operating system properly when I think its reasonable to expect
>mainstream hardware to work, eg. realtek is mainstream and common as a

A realtek as in rl (not re) works quite well (as in stable,
predictable performance)-- we buy these for about $5 each from our
supplier and are quite common.  While it would be nice that all
network cards worked as well as the em nics, its an issue that is
easy to work around-- after all, I would rather be limited by my nic
driver choice as opposed to vm and network stack issues which I cant
work around.  Also thankfully, a large chunk of the server MB market
uses em nics.  Yes, bge/bce based nics do seem to perform poorly on
FreeBSD.  Hopefully Broadcom might put similar resources into driver
development as Intel does/has.

         ---Mike

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Chris-69
In reply to this post by Tom Evans-3
On 29/02/2008, Tom Evans <[hidden email]> wrote:

> On Fri, 2008-02-29 at 15:44 +0000, Chris wrote:
> > On 29/02/2008, Ted Mittelstaedt <[hidden email]> wrote:
> >
> > A weakness of freebsd is its fussyness over hardware in particular
> > network cards, time and time again I see posts here telling people to
> > go out buying expensive intel pro 1000 cards just so they can use the
> > operating system properly when I think its reasonable to expect
> > mainstream hardware to work, eg. realtek is mainstream and common as a
> > onboard nic but the support in freebsd is poor and only serving
> > datacentres to shy away from freebsd.  If the same hardware performs
> > better in linux then the hardware isnt to blame for worser performance
> > in fbsd.
> >
> > Chris
>
> Not to come down too hard on you, but the reason why Pro/1000 chipsets
> are reasonably pricey, and uncommon to find as an integrated NIC, except
> on server boards or intel own brand mobos, is that it is decent
> hardware, and hence costs real money to use. Consumer NICs like Realtek,
> Via Rhine and (imo) Marvell are cheap tat that 'just about' works, until
> you put it under heavy stress. I have encountered a series of Marvell
> based chips on my personal home computers that work about as well as a
> slap around the face. Also, even from the 'good' manufacturers, like
> broadcom and intel, you have 'consumer' parts, which are reasonably
> cheap, like bge(4) supported parts, and 'professional' parts, like
> bce(4) parts. One should work fine under moderate load, one should work
> fine under heavy load. One will cost $4, one will cost $100.
>
> I'm not saying the drivers are bug-free, but if you want performance and
> reliability, you get an em(4) or another professional chipset. Only a
> few months ago at work, we had to  order around 75 Pro/1000s as we had
> had enough of crashes from our bce(4) based integrated NICs on our Dell
> 2950s. Fortunately for our wallet, we managed to fix the issues in the
> driver/hardware before our supplier could source that many - thanks
> David Christensen!
>
> Personally, I wouldn't put something in a data-centre with only a vr(4)
> or re(4), regardless of OS.
>
> Tom
>
>
>

You working round what I just said.  A nic should perform equally well
as it does in other operating systems just because its cheaper its not
an excuse for buggy performance.  There is also other good network
cards apart from intel pro 1000.  I am talking about stability not
performance, I expect a intel pro 1000 to outperform a realtek however
I expect both to be stable in terms of connectivity.  I expect a
realtek in freebsd to perform as well as a realtek in windows and
linux. :)

We have our own opinions but for many tasks a vr re bge etc. even a rl
does the job its required just fine.  I have seen linux servers using
rl adaptors outperform freebsd servers with superior cards because the
linux driver is better.  I do agree its a sad state of affairs
datacentres like to rent out servers built from desktop parts but
unfurtenatly thats the market for you unless paying a premium or going
with own hardware colocated.

Chris
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: FreeBSD bind performance in FreeBSD 7

Ted Mittelstaedt
In reply to this post by Chris-69


> -----Original Message-----
> From: Chris [mailto:[hidden email]]
> Sent: Friday, February 29, 2008 7:45 AM
> To: Ted Mittelstaedt
> Cc: Sam Leffler; [hidden email]; Oliver Herold; Kris
> Kennaway; [hidden email]
> Subject: Re: FreeBSD bind performance in FreeBSD 7
>

> A weakness of freebsd is its fussyness over hardware in particular
> network cards, time and time again I see posts here telling people to
> go out buying expensive intel pro 1000 cards just so they can use the
> operating system properly when I think its reasonable to expect
> mainstream hardware to work, eg. realtek is mainstream and common as a
> onboard nic but the support in freebsd is poor and only serving
> datacentres to shy away from freebsd.  If the same hardware performs
> better in linux then the hardware isnt to blame for worser performance
> in fbsd.
>

Device drivers and hardware are a cooperative effort.  The ideal
is a well-written device driver and well-designed hardware.
Unfortunately the reality of it appears to be that it costs
a LOT more money to hire good silicon designers than it costs
to hire good programmers - so a depressing amount of computer
hardware out there is very poor hardware, but the hardware's
shortcomings are made up by almost Herculean efforts of the
software developers.

I should have thought the invention of the Winmodem (windows-only
modem) would have made this obvious to the general public
years ago.

Unfortunately, the hardware vendors make a lot of effort to
conceal the crappiness of their designs and most customers
just care if the device works, they don't care if the only
way the device can work is if 60% of their system's CPU is
tied up servicing a device driver that is making up for
hardware shortcomings, so it is still rather difficult
for a customer to become informed about what is good and
what isn't - other than trial and error.

I hardly think that the example I cited - the 3com 3c905 PCI
network adapter - is an example of poor support in FreeBSD.
The FreeBSD driver for the 509 worked perfectly well when
the 309 used a Lucent-built ASIC.  When 3com decided to
save 50 cents a card by switching to Broadcom for the
ASIC manufacturing, the FreeBSD driver didn't work very
well with those cards - nor did the Linux driver for that
matter.  This clearly wasn't a driver problem it was a
problem with Broadcom not following 3com's design specs
properly.  3com did the only thing they could - which
was to put a hack into the Windows driver - but of course,
nobody bothered telling the Linux or FreeBSD community
about it, we had to find out by dicking around with the
driver code.

If datacenters want to purchase poor hardware and run their
stuff on it, that's their choice.  Just because a piece
of hardware is "mainstream" doesen't mean it's good.  It
mainly means it's inexpensive.

Ted
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Fred C-3
In reply to this post by Chris-69

On Feb 29, 2008, at 7:44 AM, Chris wrote:

>
> A weakness of freebsd is its fussyness over hardware in particular
> network cards, time and time again I see posts here telling people to
> go out buying expensive intel pro 1000 cards just so they can use the
> operating system properly when I think its reasonable to expect
> mainstream hardware to work, eg. realtek is mainstream and common as a
> onboard nic but the support in freebsd is poor and only serving
> datacentres to shy away from freebsd.  If the same hardware performs
> better in linux then the hardware isnt to blame for worser performance
> in fbsd.
>

The weakness comes mainly from the hardware.

It is like Nascar, you don't run Nascar in your everyday Prius. You  
need a car with stronger and ultra performing components. Your Prius  
maybe fine for your commute and your grocery shopping, but when it  
comes to a race it will perform very badly.

Here the problem is the same. For your everyday home desktop machine  
any low end network card is fine. But when you want to handle several  
thousand connections per seconds you need some some hardware who can  
handle it.

--
Fred C!
PGP-KeyID: E7EA02EC3B487EE9
PGP-FingerPrint: A906101E2CCDBB18D7BD09AEE7EA02EC3B487EE9



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Adrian Chadd-2
In reply to this post by Chris-69
On 01/03/2008, Chris <[hidden email]> wrote:

> You working round what I just said.  A nic should perform equally well
>  as it does in other operating systems just because its cheaper its not
>  an excuse for buggy performance.  There is also other good network
>  cards apart from intel pro 1000.  I am talking about stability not
>  performance, I expect a intel pro 1000 to outperform a realtek however
>  I expect both to be stable in terms of connectivity.  I expect a
>  realtek in freebsd to perform as well as a realtek in windows and
>  linux. :)

Patches please!


Adrian


--
Adrian Chadd - [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Chris-69
On 01/03/2008, Adrian Chadd <[hidden email]> wrote:

> On 01/03/2008, Chris <[hidden email]> wrote:
>
> > You working round what I just said.  A nic should perform equally well
> >  as it does in other operating systems just because its cheaper its not
> >  an excuse for buggy performance.  There is also other good network
> >  cards apart from intel pro 1000.  I am talking about stability not
> >  performance, I expect a intel pro 1000 to outperform a realtek however
> >  I expect both to be stable in terms of connectivity.  I expect a
> >  realtek in freebsd to perform as well as a realtek in windows and
> >  linux. :)
>
> Patches please!
>
>
> Adrian
>
>
> --
> Adrian Chadd - [hidden email]
>

Ironically the latest server I got last night has a intel pro 1000 a rarity :)

I am just giving feedback as when I speak to people in the datacentre
and hosting business the biggest gripe with freebsd is hardware
compatability, as I adore freebsd I ignore this and work round it but
its defenitly reducing take up.

Of course I know current re issues are getting attention which I am
thankful for, I fully understand the time and effort required to write
drivers patches etc. and have got no critisicms for the people who do
this my complaint is more focused on people claiming there is no
issues its just the hardware.

Thanks

Chris
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Christian Brueffer-2
On Sat, Mar 01, 2008 at 02:20:58AM +0000, Chris wrote:

> On 01/03/2008, Adrian Chadd <[hidden email]> wrote:
> > On 01/03/2008, Chris <[hidden email]> wrote:
> >
> > > You working round what I just said.  A nic should perform equally well
> > >  as it does in other operating systems just because its cheaper its not
> > >  an excuse for buggy performance.  There is also other good network
> > >  cards apart from intel pro 1000.  I am talking about stability not
> > >  performance, I expect a intel pro 1000 to outperform a realtek however
> > >  I expect both to be stable in terms of connectivity.  I expect a
> > >  realtek in freebsd to perform as well as a realtek in windows and
> > >  linux. :)
> >
> > Patches please!
> >
> >
> > Adrian
> >
> >
> > --
> > Adrian Chadd - [hidden email]
> >
>
> Ironically the latest server I got last night has a intel pro 1000 a rarity :)
>
> I am just giving feedback as when I speak to people in the datacentre
> and hosting business the biggest gripe with freebsd is hardware
> compatability, as I adore freebsd I ignore this and work round it but
> its defenitly reducing take up.
>
> Of course I know current re issues are getting attention which I am
> thankful for, I fully understand the time and effort required to write
> drivers patches etc. and have got no critisicms for the people who do
> this my complaint is more focused on people claiming there is no
> issues its just the hardware.
>
Pyun YongHyeon has fixed a lot of driver issues (i.e. re(4), bfr(4), vr(4))
over the last few months, many are already in CURRENT or RELENG_7 (not
sure how many of them made it into 7.0-RELEASE) or posted as patches
to the current@ mailing list.

If you have problems, please see if they persist with a CURRENT snapshot.
If they do, please post to the current@ mailing list with details.

- Christian

--
Christian Brueffer [hidden email] [hidden email]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Robert N. M. Watson-2
In reply to this post by Chris-69

On Sat, 1 Mar 2008, Chris wrote:

> Ironically the latest server I got last night has a intel pro 1000 a rarity
> :)
>
> I am just giving feedback as when I speak to people in the datacentre and
> hosting business the biggest gripe with freebsd is hardware compatability,
> as I adore freebsd I ignore this and work round it but its defenitly
> reducing take up.
>
> Of course I know current re issues are getting attention which I am thankful
> for, I fully understand the time and effort required to write drivers
> patches etc. and have got no critisicms for the people who do this my
> complaint is more focused on people claiming there is no issues its just the
> hardware.

It's no coincidence that Intel cards work quite well with FreeBSD, given that
Intel has hired developers to make FreeBSD work well on their cards.  The same
goes for companies like Broadcom, Chelsio, Neterion, etc, who provide not only
the necessary documentation, but also put development resources into writing
and QAing drivers.  Put pressure on your hardware providers to do the same
thing for their hardware -- one or two people asking may not do the trick, but
a few large customers beating on their sales engineers can make a big
difference, and so can larger numbers of smaller customers.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade from 6.3 to 7.0: Result ->Shared object not found :)

Aleksey Perov
In reply to this post by Stefan Lambrev-2
Stefan Lambrev wrote:

> Also you can use script(1) to log, so you can analyze the output latter.
> I'm not sure how script will run, if it is started in screen
> (ports/sysutils/screen)

Works just fine for me:

        screen script portupgrade.log portupgrade -a



--
Aleksey
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Thomas Krause (Webmatic)
In reply to this post by Christian Brueffer-2
>>
>
> Pyun YongHyeon has fixed a lot of driver issues (i.e. re(4), bfr(4), vr(4))
> over the last few months, many are already in CURRENT or RELENG_7 (not
> sure how many of them made it into 7.0-RELEASE) or posted as patches
> to the current@ mailing list.

My question is: which other PCI-Express GBit NIC's then Intel's are
available on the market? I can't find others ...

Best regards,
Thomas.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

PCIe vs PCI (was: Re: FreeBSD bind performance in FreeBSD 7)

dieter-7
> My question is: which other PCI-Express GBit NIC's then Intel's are
> available on the market? I can't find others ...

"man -k pcie" on 6.2 gives:

bce(4) - Broadcom NetXtreme II (BCM5706/BCM5708) PCI/PCIe Gigabit Ethernet adapter driver
re(4)  - RealTek 8139C+/8169/816xS/811xS/8101E PCI/PCIe Ethernet adapter driver

There might be more in 7.0 but it is still downloading.  :-(
And there may be PCIe devices that don't show up in man -k.
Is there a way to tell from dmesg or pciconf that something is
PCIe rather than PCI?  The onboard stuff could be either.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Christian Brueffer-2
In reply to this post by Thomas Krause (Webmatic)
On Mon, Mar 03, 2008 at 09:52:22AM +0100, Thomas Krause (Webmatic) wrote:

> >>
> >
> >Pyun YongHyeon has fixed a lot of driver issues (i.e. re(4), bfr(4), vr(4))
> >over the last few months, many are already in CURRENT or RELENG_7 (not
> >sure how many of them made it into 7.0-RELEASE) or posted as patches
> >to the current@ mailing list.
>
> My question is: which other PCI-Express GBit NIC's then Intel's are
> available on the market? I can't find others ...
>
Googling for "pci express gigabit ethernet" gives quite a few hits.

- Christian

--
Christian Brueffer [hidden email] [hidden email]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PCIe vs PCI (was: Re: FreeBSD bind performance in FreeBSD 7)

Zaphod Beeblebrox-2
In reply to this post by dieter-7
On Mon, Mar 3, 2008 at 8:42 AM, Dieter <[hidden email]> wrote:

> > My question is: which other PCI-Express GBit NIC's then Intel's are
> > available on the market? I can't find others ...
>
> "man -k pcie" on 6.2 gives:


AFAIK, PCIe devices show up as PCI devices to most drivers.  I know that
'em' flavor drivers work fine with PCIe and that 'ath' driver also does (in
this case, the ath is an 'express card' ... which I'm told is another flavor
of PCIe).  I think the only oddball thing about PCIe is that some flavours
of PCIe can show up as a USB device rather than a PCI device.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

mdtancsa
In reply to this post by Thomas Krause (Webmatic)
At 03:52 AM 3/3/2008, Thomas Krause (Webmatic) wrote:

>>Pyun YongHyeon has fixed a lot of driver issues (i.e. re(4), bfr(4), vr(4))
>>over the last few months, many are already in CURRENT or RELENG_7 (not
>>sure how many of them made it into 7.0-RELEASE) or posted as patches
>>to the current@ mailing list.
>
>My question is: which other PCI-Express GBit NIC's then Intel's are
>available on the market? I can't find others ...

I have used a few bge nics that are PCIe.... However, I suggest stick
with the Intel for now.

My home box has a PCIe bge nic. It works fine for my home server on
RELENG_7 (Samba, nfs).

bge0@pci0:2:0:0:        class=0x020000 card=0x167714e4
chip=0x167714e4 rev=0x01 hdr=0x00
     vendor     = 'Broadcom Corporation'
     device     = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
     class      = network
     subclass   = ethernet
     cap 01[48] = powerspec 2  supports D0 D3  current D0
     cap 03[50] = VPD
     cap 05[58] = MSI supports 8 messages, 64 bit
     cap 10[d0] = PCI-Express 1 endpoint
bge0: <HPQ 10/100/1000 Copper Based Gigabit Adapter, ASIC rev.
0x4001> mem 0xfddf0000-0xfddfffff irq 18 at device 0.0 on pci2
miibus0: <MII bus> on bge0
brgphy0: <BCM5750 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge0: Ethernet address: 00:10:18:14:15:43
bge0: [ITHREAD]

         ---Mike

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: FreeBSD bind performance in FreeBSD 7

Ted Mittelstaedt
In reply to this post by Chris-69


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Chris
> Sent: Friday, February 29, 2008 6:21 PM
> To: Adrian Chadd
> Cc: [hidden email]; [hidden email]
> Subject: Re: FreeBSD bind performance in FreeBSD 7
>
>
> On 01/03/2008, Adrian Chadd <[hidden email]> wrote:
> > On 01/03/2008, Chris <[hidden email]> wrote:
> >
> > > You working round what I just said.  A nic should perform equally well
> > >  as it does in other operating systems just because its
> cheaper its not
> > >  an excuse for buggy performance.  There is also other good network
> > >  cards apart from intel pro 1000.  I am talking about stability not
> > >  performance, I expect a intel pro 1000 to outperform a
> realtek however
> > >  I expect both to be stable in terms of connectivity.  I expect a
> > >  realtek in freebsd to perform as well as a realtek in windows and
> > >  linux. :)
> >
> > Patches please!
> >
> >
> > Adrian
> >
> >
> > --
> > Adrian Chadd - [hidden email]
> >
>
> Ironically the latest server I got last night has a intel pro
> 1000 a rarity :)
>
> I am just giving feedback as when I speak to people in the datacentre
> and hosting business the biggest gripe with freebsd is hardware
> compatability, as I adore freebsd I ignore this and work round it but
> its defenitly reducing take up.
>
> Of course I know current re issues are getting attention which I am
> thankful for, I fully understand the time and effort required to write
> drivers patches etc. and have got no critisicms for the people who do
> this my complaint is more focused on people claiming there is no
> issues its just the hardware.
>

There aren't issues on hardware that is compatible.

You can't run MacOS X on an off-the-shelf PC and nobody
complains about it.  You can't run Solaris for the Sparc
on an Intel box but nobody complains about it.  FreeBSD
is not Java, it is not "write once, run anywhere"

If there is any problem with FreeBSD in this respect is that
it supports the poor hardware AT ALL.  Of course, we can't
do much about that - a code contributor who gets access
to CVS can put anything they want into the FreeBSD source,
and drivers are a particular problem - since few developers
are going to have duplicates of the hardware, only the
contributing developer really knows if his driver is solid
or not.

Arguably it might be better to drop support for poor hardware,
then the people who had such hardware would not be tempted
to run FreeBSD - thereby having a bad experience with it,
and blaming FreeBSD about it.

I challenge you to find an example of very high quality
hardware that has a driver in FreeBSD that has a lot of
problems.  Yet, you can find a lot of poor quality hardware
that has a FreeBSD driver with a lot of problems.  That
should tell you something - that the issue for the poor
hardware really is "just the hardware"

The people complaining about hardware compatibility need
to pull their heads out.  If they are buying brand new systems
they are utter fools if they don't check out in advance
what works and what doesen't.  It's not like there's a
shortage of experienced people on this list who could
tell them what to buy.  And if after the fact they find out
their shiny new PC won't run FreeBSD - then they take it
back to the retailer and exchange it for a different model.
Why is this so difficult?

My beef with the DNS tests was that ISC ran out and bought
the hardware FIRST, -then- they started testing.  This is
directly contrary to every bit of advice ever given in
the computer industry for the last 50 years - you select
the software FIRST, -then- you buy the hardware that runs it.
In short, it said far more about the incompetence of the
testers than the shortcomings of the software.

The people who have USED systems who are bitching about
FreeBSD not being compatible with their stuff need to
get over it.  OK, so they didn't get a chance to select
the hardware, they are using some retired Windows box
that won't run the new version of Windows.  So they come
here and our stuff has a problem with some hardware
part.  Well, OK fine - how does this hurt them?  Their
old computer wasn't usable for Windows anymore, now was it?
In short, their computer at that point was worthless - and
why is it OUR responsibility to make our stuff compatible
with their old computer?  How does us being incompatible
take anything away from them - their computer was scrap
anyway.  If there's a problem, well they can go
to the computer junkyard and exchange their scrap computer
for a different old scrap computer that has compatible
parts.

Ted

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Peter Losher
Ted Mittelstaedt wrote:

> My beef with the DNS tests was that ISC ran out and bought
> the hardware FIRST, -then- they started testing.  This is
> directly contrary to every bit of advice ever given in
> the computer industry for the last 50 years - you select
> the software FIRST, -then- you buy the hardware that runs it.
> In short, it said far more about the incompetence of the
> testers than the shortcomings of the software.

This is ridiculous.  ISC is one of the most fervent pro-FreeBSD
companies out there (basing most of our services on the OS, and
contributing to the FreeBSD community including the busiest CVSup & FTP
servers and have FreeBSD committers on staff)  I will not stand back and
watch folks on a public mailing list call us incompetent individuals
with a anti-FreeBSD bias.

First off the final report was published last Friday at:
http://www.isc.org/pubs/tn/index.pl?tn=isc-tn-2008-1.html
(the server this is served from runs FreeBSD)

I was not one of the direct testers (we had a couple PhD's handling
that, who I know both use FreeBSD on their personal systems), but as one
of the folks who supported them in their work, I can tell you that the
stats we gave the FreeBSD folks were from a test sponsored by the US
National Science Foundation.  We were mandated to use branded HW and we
tested several models from HP, Sun, even Iron Systems (whitebox) before
deciding on the HP's.  The mechanism we used are all documented in the
paper We were also asked to test DNS performance on several OS's.

The short version was 'take a standard commercial off the shelf' server
and see how BIND performs (esp. with DNSSEC) on it.  We weren't asked to
get hardware that was perfect for Brand X OS; that wasn't part of the remit.

(We actually use the exact same HP HW for a secondary service where we
host a couple of thousand zones using BIND including 30+ TLD zones.  Oh
and it runs FreeBSD)

Yes we found FreeBSD performed poorly in our initial tests. and I talked
to several folks (including rwatson and kris) about the issue.  Kris had
already been working on improving performance with MySQL and PgSQL and
was interested in doing the same with BIND.  Kris went off and hacked
away and right before EuroBSDcon last September asked us to re-run the
tests (on the same HW) using a 7.0-CURRENT snapshot, and the end results
are shown with a 33,000 query increase over 6.2-RELEASE, bring FreeBSD
just behind the Linux distros we tested.  I know rwatson and kris have
continually worked on the relevent network stack issues that cover BIND,
and additional performance gains have been found since then, and working
on this issue has been a true partnership between the FreeBSD developers
and ISC.

BIND isn't perfect, we admit that, we have been constantly improving
it's multi-CPU performance and BIND 9.4 and 9.5 are continuing in that
effort.  We have several members of our dev team who use FreeBSD as
their developent platform, including a FreeBSD committer.

So Ted, stop spouting this "ISC is spewing anti-FreeBSD bias" crap, it
flatly isn't true...

Oh, and this email is coming to you via several of ISC FreeBSD MX
servers which resolve the freebsd.org name via caching DNS servers
running FreeBSD, to freebsd.org's MX server over a IPv6 tunnel supplied
by ISC to the FreeBSD project to help FreeBSD eat their own IPv6 dog food...

Yeah, ISC just hates FreeBSD... <rolls eyes>

Best Wishes - Peter
--
[hidden email] | ISC | OpenPGP 0xE8048D08 | "The bits must flow"


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PCIe vs PCI

Thomas Krause (Webmatic)
In reply to this post by dieter-7



Dieter schrieb:

>> My question is: which other PCI-Express GBit NIC's then Intel's are
>> available on the market? I can't find others ...
>
> "man -k pcie" on 6.2 gives:
>
> bce(4) - Broadcom NetXtreme II (BCM5706/BCM5708) PCI/PCIe Gigabit Ethernet adapter driver
> re(4)  - RealTek 8139C+/8169/816xS/811xS/8101E PCI/PCIe Ethernet adapter driver
>
> There might be more in 7.0 but it is still downloading.  :-(
> And there may be PCIe devices that don't show up in man -k.
> Is there a way to tell from dmesg or pciconf that something is
> PCIe rather than PCI?  The onboard stuff could be either.

I don't speak from onboard cards! I speak from PCI-E cards you
can plug into the PCI-E slot. E.g. in Ingram Micros online shop
there are only Intel PCI-E-Cards listed. I know there are good
PCI-E NIC's from Sysconnect, but I can only buy them from special
dealers. Compared to PCI-NIC's - I realy don't have a big choice of
PCI-E NIC's.

Regards,
Thomas.


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Chris-69
In reply to this post by Ted Mittelstaedt
On 29/02/2008, Ted Mittelstaedt <[hidden email]> wrote:
>
>

>
> Device drivers and hardware are a cooperative effort.  The ideal
> is a well-written device driver and well-designed hardware.
> Unfortunately the reality of it appears to be that it costs
> a LOT more money to hire good silicon designers than it costs
> to hire good programmers - so a depressing amount of computer
> hardware out there is very poor hardware, but the hardware's
> shortcomings are made up by almost Herculean efforts of the
> software developers.
>
> I should have thought the invention of the Winmodem (windows-only
> modem) would have made this obvious to the general public
> years ago.
>
> Unfortunately, the hardware vendors make a lot of effort to
> conceal the crappiness of their designs and most customers
> just care if the device works, they don't care if the only
> way the device can work is if 60% of their system's CPU is
> tied up servicing a device driver that is making up for
> hardware shortcomings, so it is still rather difficult
> for a customer to become informed about what is good and
> what isn't - other than trial and error.
>
> I hardly think that the example I cited - the 3com 3c905 PCI
> network adapter - is an example of poor support in FreeBSD.
> The FreeBSD driver for the 509 worked perfectly well when
> the 309 used a Lucent-built ASIC.  When 3com decided to
> save 50 cents a card by switching to Broadcom for the
> ASIC manufacturing, the FreeBSD driver didn't work very
> well with those cards - nor did the Linux driver for that
> matter.  This clearly wasn't a driver problem it was a
> problem with Broadcom not following 3com's design specs
> properly.  3com did the only thing they could - which
> was to put a hack into the Windows driver - but of course,
> nobody bothered telling the Linux or FreeBSD community
> about it, we had to find out by dicking around with the
> driver code.
>
> If datacenters want to purchase poor hardware and run their
> stuff on it, that's their choice.  Just because a piece
> of hardware is "mainstream" doesen't mean it's good.  It
> mainly means it's inexpensive.
>
> Ted
>

Ted I never meant mainstream = good but I did mean mainstream cannot
be ignored and written off if something is mainstream it is for a
reason if the hardware was so poor then I am sure complaints would be
so high it would no longer be mainstream.  Not sure if you
understanding me I am most defenitly not saying I expect a cheap
network card to perform on par with a premium card.  I am merely
saying ideally it should perform and be as stable as it is in other
operating systems and if it isnt then look at what can be improved
rather than just saying go buy a new peice of kit.  Is freebsd a
operating system for use on premium hardware only? as that what it
feels like I am reading sometimes.

Now on the bind tests if the hardware used on both linux and freebsd
was the exact same spec hardware then blaming the hardware is invalid
as its apple vs apple.  Obviously if the linux tests were done on
superior hardware then its apple vs orange and the tests are
invalidated.

Chris
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FreeBSD bind performance in FreeBSD 7

Mark Linimon-2
In reply to this post by Ted Mittelstaedt
> > * 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.

If this is true, please try to explain to me the following:

 - ISC hosts 5 Netra 1s that comprise most of our sparc64 package build
   cluster.  They are allowing us to add 4 more next week.

 - ISC hosts 3 amd64 machines for our amd64 package build cluster.

 - ISC used to host 3 alpha machines, until we retired them.

 - ISC hosts ftp4.freebsd.org, which is one of the 2 machines that the
   address ftp.freebsd.org rotors to.  This is an extremely high-
   bandwidth machine.

 - ISC hosts several other development machines (I am not aware of
   all the exact ones).

All of this has been in place for years, with the space, power, and
cooling all donated for free.

Kris and others have been doing a tremendous amount of work over the
past 2 years to identify and fix performance problems in FreeBSD.
There have been literally hundreds of regression tests run, resulting
in a large number of cycles of commit/test.  Sometimes the commits do
what we expect, sometimes no.  Lather, rinse, repeat.  The difference
in performance between 6.3R and 7.0R is primarily due to all this
effort.  ISC's re-tests seems to confirm the improvements.

The current speculation is that the difference in the measurements we're
seeing could well be due to our drivers.  If so, let's identify and fix
the problems.  Otherwise, let's try to understand whether there are any
meaningful differences in the way the tests are being run.

Casting aspersions on someone's methodology or motives just because
you (or I) don't like the results is merely nonsense.

AFAICT ISC's business model primarily consists of them selling the
ability of bind to perform under load.  That's the variable they have
to optimize for.  Let's hope that we are part of helping them to do
just that.

mcl
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: FreeBSD bind performance in FreeBSD 7

Ted Mittelstaedt
In reply to this post by Peter Losher


> -----Original Message-----
> From: Peter Losher [mailto:[hidden email]]
> Sent: Monday, March 03, 2008 10:18 PM
> To: Ted Mittelstaedt
> Cc: [hidden email]; [hidden email]
> Subject: Re: FreeBSD bind performance in FreeBSD 7
>
>
> Yeah, ISC just hates FreeBSD... <rolls eyes>

This final report here:

ftp://ftp.isc.org/isc/dns_perf/ISC-TN-2008-1.pdf

is LIGHTYEARS different than the draft here:

http://new.isc.org/proj/dnsperf/OStest.html


The draft contains the conclusion:

"...We will use Linux Gentoo 2.6.20.7 for further production testing. We
brought these numbers to the attention of the FreeBSD development team, and
will re-test when FreeBSD 7.1 is released..."

This is completely missing in the final.  Added is a bunch of
praise of bind on commodity hardware.  And also added is the line:

"...All computers in the testbed were loaded with identical copies of
FreeBSD 7.0-RELEASE..."

which is missing in the draft.

So in other words, it certainly appears that the final is
180 degrees opposite of it's discussion of FreeBSD.  The
draft appears to suggest to avoid it - the final appears to
suggest to embrace it.

So what, exactly may I ask, were you expecting after
writing that draft?  Everyone here to be happy?

It almost seems to me like the draft was a trial balloon
floated to get the FreeBSD developers to jump in and
do some coding for you at the last minute.

But, I'll say no more about that and turn towards the
report - because it has some significant problems.

I'll start with the beginning:

"...We have been particularly interested in the performance of DNSSEC
mechanisms within the DNS protocols and on the use of BIND as a production
server for major zones..."

OK, fine and good.  However, the conclusion is rather
different:

"...Commodity hardware with BIND 9 software is fast enough by a wide margin
to run large production name service..."

What is going on here?  This project started out as
purely observational - merely interested in BIND performance -
and ended up being a proof for the hypothesis that BIND
is good enough to run large nameservers on commodity hardware.

In short, the report is moving from an objective view to a
subjective goal of proving BIND is kick-ass.

It is interesting how the original draft conclusion IS NOT subjective
with regards to BIND (it is with regards to FreeBSD of course)
and uses the phrase "further production testing" implying
that BIND is still under development, while the final report
uses the language:

"...open-source software and commodity hardware are up to the task of
providing full-scale production name..."

which definitely implies that BIND is "done" and ready for
production.

Another thing of interest concernes the OS.

Microsoft Windows 2003 server is included in
the first breaking point test.  It is absent from the other
tests.  And the version chosen is old, old, it is NOT
even Server 2003 R2, nor the RC of Server 2008 which is
available.

Why were the Windows test results even left in the
published report at all?  What purpose do they serve
other than as a feel-good "bash Windows".  If you really
were interested in the results of testing, you would
have wanted to know how BIND did under Windows for the
other tests.  But, as I pointed out, by the time the
later tests were run the goal has stopped being the
pure objective observational goal, and become the
subjective "prove BIND is the best" goal.  And as the
Windows results for the breaking test were so low, it
was an embarassment to keep bothering with it, so it
was dropped.

The report also suffers from NOT listing out the
components of the HP servers and instead offering a
link to HP.  Yeah, how long is that link going to be
valid?  HP changes it's website and changes it's product
line up as often as I change my underpants - a year from
now, that product will be gone and a new reader will have
a snowball's chance in Hell of getting the actual server
specs, and I mean the chipsets in use for the disk controller,
nic card, video, etc.  You know, the stuff that actually
-affects- the performance of different operating systems.

But the biggest hole is the report conclusion and this
shift from objective, to subjective, reporting.  The conclusion
claims BIND is great on commodity hardware but what it
ONLY has proven is that BIND is great on this one specific
hardware platform running a couple specific operating systems.

If you really wanted to merely objectively observe BIND on
commodity hardware you should have had your testers stay out of the
setup of the OS and platform.  You should have called
up the developers of the various operating systems you
were going to use - Microsoft among them - and told them
to each send in a group that would build a server to their
spec.  You should have merely set a maximum limit that the
server could cost that was in line with commodity server
hardware costs - something like $2K and it had to be name-brand,
for example - and let all of the vested interest groups do
their best to create a server that would run as fast as they could
in those constraints.

In short, if the testers are setting out to prove BIND is
really powerful, they are essentially trying to write a
benchmark.  And the way you do that is by deliberatly pulling
all the stops out to make your stuff run as lickety-split as
possible - then you document the crap out of everything you
did to make it run lickety-split, so that anyone else can
come along, set up the stuff the same way you did, and then
get the same results.  Benchmarks are subjective and they
are expected to be subjective - but when you write them,
your admitting your testers are being subjective.  In that
case, there is no point in having an OS bake-off since
your going to have your testers select the OS that will
give the best shine to your product.

The report needs to make up it's mind what it's actually trying
to accomplish, objective, or subjective, reporting.

Ted

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
123