Date: Fri, 16 Feb 2007 05:22:05 -0500 From: Vinny Abello <vinny@tellurian.com> To: Dimuthu Parussalla BWEADM non-std-pwd <dparussalla@baysidegrp.com.au> Cc: freebsd-stable@freebsd.org Subject: Re: Slow network performance Message-ID: <45D585CD.80805@tellurian.com> In-Reply-To: <20070216063419.81558.qmail@baysidegrp.com.au> References: <001a01c7513e$bc0cb4c0$d801a8c0@dimuthu> <45D52987.6090505@tellurian.com> <20070216063419.81558.qmail@baysidegrp.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
This sounds like your switch and host settings are correct so I wouldn't spend too much more time looking at that at this point. I just wanted to mention it to be sure. Good luck! Dimuthu Parussalla BWEADM non-std-pwd wrote: > This is exactly what I did. > Managed Switch A (2950G) > 1) both switch and bge/em card set for auto negeotiation > 2) Both switch and bge/em set for 1000mb full-duplex. > > Managed Switch B (Netgeat GSM7224) > 1) both switch and bge/em card set for auto negeotiation > 2) Both switch and bge/em set for 1000mb full-duplex. > > I am seriously running out of options. > Thanks > > Vinny Abello writes: >> 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" >> _______________________________________________ >> 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?45D585CD.80805>