Re: Slow network performance
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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 192.168.1.12 netmask 0xff00 broadcast 192.168.1.255 ether 00:0e:0c:d0:73:3c media: Ethernet 1000baseTX full-duplex status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 6x.xx.xx.xx netmask 0xffc0 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 [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow network performance
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 What have you done to rule out if it's a faulty cable or noise on the cable? What kind of cable is it? net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 Are you sure these two should be set to the millions? Try reducing them to ~32k or so. -- Sten Daniel Soersdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Slow network performance
Hi Sten, I have ruled out the faulty cable. Also no errors reporting on the managed switch. Doing a test with a reduced parameters to 32k. -Original Message- From: Sten Daniel Soersdal [mailto:[EMAIL PROTECTED] Sent: Saturday, 17 February 2007 2:33 AM To: Dimuthu Parussalla BWEADM non-std-pwd Cc: Vinny Abello; freebsd-stable@freebsd.org Subject: Re: Slow network performance 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 What have you done to rule out if it's a faulty cable or noise on the cable? What kind of cable is it? net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 Are you sure these two should be set to the millions? Try reducing them to ~32k or so. -- Sten Daniel Soersdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Slow network performance
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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 192.168.1.12 netmask 0xff00 broadcast 192.168.1.255 ether 00:0e:0c:d0:73:3c media: Ethernet 1000baseTX full-duplex status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 6x.xx.xx.xx netmask 0xffc0 broadcast xxx.xxx.xxx.255 ether 00:0e:0c:9f:f4:5e media: Ethernet 100baseTX full-duplex status: active Regards Dimuthu Parussalla # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.7.2.2 2006/05/01 00:15:12 scottl Exp $ machine i386 cpu I686_CPU ident BSG maxusers512 # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols #optionsSCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug options SMP # SMP Support # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic# I/O APIC options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options IPFILTER options IPFILTER_LOG #optionsIPFILTER_DEFAULT_TO_ACCEPT options IPSEC options IPSEC_ESP options IPSEC_DEBUG #options IPTUNNEL #options NCP options NETATALK options DUMMYNET #options TCP_RESTRICT_RST options QUOTA options BRIDGE # Bus support. #device eisa device pci # Floppy drives device fdc # ATA and ATAPI
Re: Slow network performance
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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 192.168.1.12 netmask 0xff00 broadcast 192.168.1.255 ether 00:0e:0c:d0:73:3c media: Ethernet 1000baseTX full-duplex status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 6x.xx.xx.xx netmask 0xffc0 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 [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow network performance
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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 192.168.1.12 netmask 0xff00 broadcast 192.168.1.255 ether 00:0e:0c:d0:73:3c media: Ethernet 1000baseTX full-duplex status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 6x.xx.xx.xx netmask 0xffc0 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 [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
