7.1-PRERELEASE : bad network performance (nfe0)

[firmdog at gmail.com]

On Sun, Sep 28, 2008 at 6:24 PM, Jeremy Chadwick <koitsu at freebsd.org> wrote:

> On Sun, Sep 28, 2008 at 06:15:43PM -0400, firmdog at gmail.com wrote:
> > On Sun, Sep 28, 2008 at 4:53 PM, Gary Palmer <gpalmer at freebsd.org>
> wrote:
> >
> > > On Sun, Sep 28, 2008 at 01:43:12PM -0400, firmdog at gmail.com wrote:
> > > > I have the same problem on a Dell Poweredge SC440 when I transferred
> over
> > > > 50GB
> > > > from a FreeBSD 5.4 box to my new Dell running 7.1.  Used a crossover
> > > cable
> > > > and
> > > > the link was 1000 full duplex, but could only get about 10M/s.  Very
> odd.
> > > > Did a
> > > > tcpdump and saw lots of bad checksum errors.
> > > >
> > > > What other troubleshooting steps can we take?  What could be the
> problem?
> > >
> > > Please post the first few lines of ifconfig for bge0.  I'm suspecting
> > > you'll see something like
> > >
> > > em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > >        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
> > >
> > > (yes, I know thats an em, not bge, but I don't have any bge's around
> > >  here)
> > >
> > > Note that the options line say that receive and transmit checksum
> > > offloading is enabled.  This means that for packets transmitted
> > > by this system, tcpdump will show checksum errors as the kernel
> > > is not generating the checksums, the ethernet card will.  Since
> > > tcpdump is seeting the packet before the ethernet card does its
> > > magic, you get the checksum errors on transmit.  Received packets
> > > should be fine though.
> > >
> > > Regards,
> > >
> > > Gary
> > >
> >
> >
> > Pasted below.  When I was doing the transfer, it was 1000 full duplex and
> > was very slow.
> > This is a web/email/database server and I don't see any performance
> problems
> > yet, but
> > I would like to know what the problem is/was.  What else can I provide?
> >
> > bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> 1500
> >         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
> >         ether 00:1a:a0:23:c0:03
> >         inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
> >         media: Ethernet autoselect (100baseTX <full-duplex>)
> >         status: active
>
> I see 100baseTX there, not 1000baseTX.  This speed is being selected via
> autoneg (auto speed/duplex negotiation).
>
> Whatever switch you're connected to is not properly negotiating the
> speed.
>
> What brand and model of switch is this host connected to, and are you
> *absolutely certain* it supports (and is configured for) gigE?



No....you misunderstood.  The 7.1 box was connected to a 5.4 box doing a
50GB
data transfer over rsync.  Both nics were 1000 full duplex with a crossover
cable.
The speed performance was terrible and I could only get up to 10 Mb/s and
there
was NO switch involved.  I believe there is a problem or bug involved with
the
driver.  Have the drivers or stack been updated in 7.1?  What else can I
provide?