Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Feb 2007 22:48:23 -0500
From:      Vinny Abello <vinny@tellurian.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Slow network performance
Message-ID:  <45D52987.6090505@tellurian.com>
In-Reply-To: <001a01c7513e$bc0cb4c0$d801a8c0@dimuthu>
References:  <001a01c7513e$bc0cb4c0$d801a8c0@dimuthu>

next in thread | previous in thread | raw e-mail | index | archive | help
Although I don't think this is necessarily the cause of your dropouts as you put it, one must understand the way autonegotiation and manual speed and duplex work between network gear.

For autonegotiation to work, BOTH devices must support autonegotiation, OR both devices must be set to the same speed and duplex setting. If one only supports auto and the other does not, you must NOT set the device that you can manually configure to full duplex. The auto device will never negotiate at full duplex and fall back to half when autonegotiation fails, causing a duplex mismatch and horrible network performance and loss.

A very rough set of rules of thumb (YMMV):

When connecting to an unmanaged switch, use auto. If your host doesn't support auto, set it to half-duplex.

When connecting to a managed switch, make sure the port is set to auto and set your system to auto, otherwise force both the switch port and your host to the same settings. This is required especially if the host doesn't support auto negotiation and you want to run at full duplex.

When connecting to a managed switch, enable portfast or the equivalent spanning-tree command on the switch port your host is connected to so it forwards traffic immediately when getting link.


So to sum it up, auto only works if both sides speak auto. Auto negotiation failure falls back to half-duplex!

Of course there are all the horror stories where auto negotiation is evil and that different vendor's implementations don't play nice or are just completely broken, so always set things to manual or you and your family will suffer an untimely death... There are so many of these stories that one would think there has to be some truth to it. In my own experience, I have never had an issue with auto negotiation in some ten years of working with a dozen different vendors' networking gear so I guess I'm lucky... or I just understand how it interacts with other devices and their capabilities. I still don't know which exactly.


Hope this helps! :)


Dimuthu Parussalla wrote:
> Hi All,
> 
> Apart from random dropout from the network. Our IBM X236 server suffers slow
> network performance. I've changed the server from CISCO switch to a netgear
> switch on a test platform. Also tried 1000m full-duplex setup with no auto
> negotionation on both ends. Still after few days (3-4) server drops the
> connection. And while its working I get 90KBps upload/download with ftp
> transfers.
> 
> I have treid changing BGE network cards to EM (intel 100/1000) still the
> same result. Any idea's to nail this problem?
> 
> 
> /etc/sysctl.conf
> 
> kern.ipc.maxsockbuf=8388608
> kern.ipc.somaxconn=2048
> net.inet.tcp.sendspace=3217968
> net.inet.tcp.recvspace=3217968
> net.inet.tcp.rfc1323=1
> #net.inet.tcp.rfc3042=0
> net.inet.ip.portrange.hilast=65535
> net.inet.ip.portrange.hifirst=49152
> net.inet.ip.portrange.last=65535
> net.inet.ip.portrange.first=1024
> net.inet.tcp.inflight.enable=0
> 
> 
> 
> /boot/loader.conf
> 
> kern.ipc.nmbclusters=32768
> 
> 
> Interfaces:
> 
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         options=b<RXCSUM,TXCSUM,VLAN_MTU>
>         inet 192.168.1.12 netmask 0xffffff00 broadcast 192.168.1.255
>         ether 00:0e:0c:d0:73:3c
>         media: Ethernet 1000baseTX <full-duplex>
>         status: active
> 
> em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         options=b<RXCSUM,TXCSUM,VLAN_MTU>
>         inet 6x.xx.xx.xx netmask 0xffffffc0 broadcast xxx.xxx.xxx.255
>         ether 00:0e:0c:9f:f4:5e
>         media: Ethernet 100baseTX <full-duplex>
>         status: active
> 
> 
> 
> Regards
> Dimuthu Parussalla
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45D52987.6090505>