netstat -ni - A lot of collisions...
Hi there group. I'm having trouble with a fxp0 card. When I ping it there are little lost packets, also the netstat -ni shows a lot collisions. The polling is enabled: kern.polling.idlepoll_sleeping: 1 kern.polling.stalled: 422 kern.polling.suspect: 937141 kern.polling.phase: 0 kern.polling.enable: 1 kern.polling.handlers: 1 kern.polling.residual_burst: 0 kern.polling.pending_polls: 0 kern.polling.lost_polls: 944349 kern.polling.short_ticks: 623 kern.polling.reg_frac: 20 kern.polling.user_frac: 50 kern.polling.poll_in_trap: 0 kern.polling.idle_poll: 0 kern.polling.burst_max: 150 kern.polling.each_burst: 5 kern.polling.burst: 150 hw.acpi.thermal.polling_rate: 10 What are they for? I've taken a look at the man netstat but wasn't able to find description? thanks! Here is the netstat -ni netstat -ni NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll fxp0 1500 00:08:c7:5b:53:5f 4504986 0 2093233 0 185206 fxp0 1500 112.15.128112.15.128.88 1716322 - 2108533 - - plip0 15000 00 0 0 pflog 332080 00 0 0 lo0 16384 4157762 0 4157762 0 0 lo0 16384 127 127.0.0.1 3964179 - 3964179 - - lo0 16384 ::1/128 ::1 191850 - 191850 - - lo0 16384 fe80:5::1/64 fe80:5::10 -0 - - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
Anton - Valqk wrote: > netstat -ni > NameMtu Network Address Ipkts IerrsOpkts > Oerrs Coll > fxp0 1500 00:08:c7:5b:53:5f 4504986 0 2093233 > 0 185206 Hmmm... what's the output of 'ifconfig fxp0'? Are you by any chance running this card in half-duplex mode? If you were connecting to a hub (rather than a switch) and all of your network was running half-duplex, then that level of collisions wouldn't be particularly remarkable. However nowadays basic 100Mb switches are cheap, so that would be rather unusual. However, a card that fails to autonegotiate with the switch will fall back to running at 100-half. That's generally pretty obvious because performance will be abysmal. Other alternatives are hardware problems -- try a different ethernet cable. Try plugging into a different port on the switch. Try a different computer on the cable etc. where you're seeing the problems. If none of that identifies a fault in the cabling, then it's looking more likely that your network interface has gone fubar. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: netstat -ni - A lot of collisions...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, the card is connected to a switch that is manageble and the port is set to 10Mbit Full duplex on purpose. I'm not setting the port speed manual - is that a problem when the port is not 100mbit/fd? This is the ifconfig output: fxp0: flags=18843 mtu 1500 options=48 inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 ether 00:08:c7:5b:54:a5 media: Ethernet autoselect (10baseT/UTP) status: active -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFTwENzpU6eaWiiWgRAjwgAJ4rfWbA5xDWmHE1MxWn36j2Njs/swCbBzJM Hg+zdfQGMra50Rh7k290Ofw= =DtBT -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
Anton - Valqk <[EMAIL PROTECTED]> wrote: > the card is connected to a switch that is manageble and the port is set > to 10Mbit Full duplex on purpose. > > I'm not setting the port speed manual - is that a problem when the port > is not 100mbit/fd? If you select the port parameters manually (i.e. disable autoselect), then you must do that on _both_ sides. Auto-negotiation only works correctly if both sides are using it. > This is the ifconfig output: > > fxp0: flags=18843 mtu 1500 > options=48 > inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 > inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 > ether 00:08:c7:5b:54:a5 > media: Ethernet autoselect (10baseT/UTP) > status: active That means autoselect is enabled, so you have to enable it on your switch, too. Otherwise disable it on the computer and select the port parameters (speed and duplex mode) manually there, too. By the way, the above output indicates that your NIC's auto-negotiation has selected half-duplex. You said that your switch is set to full-duplex. So there is a mismatch which explains why you are getting collisions. Fix your port settings, then the collisions will go away. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
On Mon, Nov 06, 2006 at 11:31:57AM +0200, Anton - Valqk wrote: > Well, > the card is connected to a switch that is manageble and the port is set to > 10Mbit Full duplex on purpose. > > I'm not setting the port speed manual - is that a problem when the port is > not 100mbit/fd? > This is the ifconfig output: > > fxp0: flags=18843 mtu 1500 > options=48 > inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 > inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 > ether 00:08:c7:5b:54:a5 > media: Ethernet autoselect (10baseT/UTP) > status: active I've never paid much attention to what ifconfig says, or what managed switches say, as far as speed or duplex negotiation go. Most vendors do not play well together. I'll repeat that because it needs repeating: most vendors do not play well together. Example: anyone familiar with Cisco Catalysts knows of the long-standing problem with auto-neg which ultimately requires both ends of the connection be set to 100/full. Try the following configurations: 1. FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex Switch -- forced 10/full Reboot FreeBSD box 2. FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex Switch -- auto-neg Reboot FreeBSD box 3. FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex Switch -- auto-neg Reboot FreeBSD box Regarding the reboots: changing duplex/speed via ifconfig once the driver has already done its initial auto-negotiation appears to behave differently with some switches than on an actual boot-up. I have no present-day evidence to back this claim up, but it's something I've seen historically with xl and fxp. Now, the transfer test I've used in the past: * Make a "small" file (dd if=/dev/urandom of=test.bin bs=64k count=256) on the FreeBSD box * Make a similar file (identical or otherwise) on another box, one that runs an FTP server * From the FreeBSD box, FTP to the FTP server * Do an FTP "PUT" of test.bin * Make note if the transfer was slow, or quick (1MByte/sec) * Now do an FTP "GET" of the file you made on the FTP server * Make note if the transfer was slow, or quick (1MByte/sec) My guess is that one of the above tests will show very fast throughput in one direction (ex. PUT), while the other direction (ex. GET) will be incredibly slow (something like 100 bytes a second, maybe less). This is what I've seen in the past in environments where a switch is set to auto-neg and the FreeBSD box claims to auto-neg to 100/full correctly... but obviously doesn't (re: see above: Cisco). You can make note of collision counts if you want, too. Any slow transfers you see will probably show up as collisions, since somewhere along the lines things got confused and chose half-duplex (even if ifconfig or the switch doesn't show it). If all of the above tests seem OK (good speed, etc. -- yet the collisions continue to increase), I recommend checking the obvious: Ethernet cable wiring. You're going to have to get a RJ45/EIA-568 cable tester and verify that all 8 wires are connected and have good continuity. You're not going to get 10/full with a Ethernet cable that's wired with only 4 wires, AFAIK. Finally: why exactly are you using 10/full? What's the purpose? Are you trying to limit the actual maximum network throughput while ensuring you have full-duplex capability? If so: look into using pf with queueing (see pf.conf man page, section QUEUEING/ALTQ), or if that's not an option, use ipfw with dummynet. Make that box use 100/full, then simply limit the actual network I/O to 10mbit. For what it's worth: I've never seen a 10/full network that worked. It was either 100/full (switches), 100/half (hubs), or 10/half (hubs). There's some discussions (use Google) about why 10/full is essentially a bastard child and should be avoided. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
On Mon, Nov 06, 2006 at 11:31:57AM +0200, Anton - Valqk wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Well, > the card is connected to a switch that is manageble and the port is set to > 10Mbit Full duplex on purpose. Your ifconfig output below shows halfduplex! > I'm not setting the port speed manual - is that a problem when the port is > not 100mbit/fd? > This is the ifconfig output: > > fxp0: flags=18843 mtu 1500 > options=48 > inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255 > inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2 > ether 00:08:c7:5b:54:a5 > media: Ethernet autoselect (10baseT/UTP) ^^^ like here. Wilko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -ni - A lot of collisions...
> I've never paid much attention to what ifconfig says, or what > managed switches say, as far as speed or duplex negotiation go. > Most vendors do not play well together. I'll repeat that because > it needs repeating: most vendors do not play well together. > Example: anyone familiar with Cisco Catalysts knows of the > long-standing problem with auto-neg which ultimately requires > both ends of the connection be set to 100/full. I disagree. Autonegotiation used to be a problem, and we used to force all links to 100/full. But that was 3-4 years ago. These days, the situation is much improved - and in most cases autonegotiation "just works". That includes *lots* of Cisco Catalyst switches. Steinar Haug, Nethelp consulting, [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: netstat -ni - A lot of collisions...
[EMAIL PROTECTED] wrote: >> I've never paid much attention to what ifconfig says, or what >> managed switches say, as far as speed or duplex negotiation go. >> Most vendors do not play well together. I'll repeat that because >> it needs repeating: most vendors do not play well together. >> Example: anyone familiar with Cisco Catalysts knows of the >> long-standing problem with auto-neg which ultimately requires >> both ends of the connection be set to 100/full. > > I disagree. Autonegotiation used to be a problem, and we used to force > all links to 100/full. But that was 3-4 years ago. These days, the > situation is much improved - and in most cases autonegotiation "just > works". That includes *lots* of Cisco Catalyst switches. Actually, we used to do the same. But nowadays it's gone completely the other way. Modern GigE capable ethernet interfaces seem to work better if you let them autonegotiate. That's even if they aren't running at Gig speed where autoneg is required by design. We've had a series of Broadcomm bge(4) network interfaces that would arbitrarily stop working if hardwired to 100-full, but that are doing just fine when allowed to autoneg. Switches are mostly HP Procurve if that makes any difference. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: netstat -ni - A lot of collisions...
On Mon, Nov 06, 2006 at 09:37:26PM +, Matthew Seaman wrote: > We've had a series of Broadcomm bge(4) network interfaces that would > arbitrarily stop working if hardwired to 100-full, but that are doing > just fine when allowed to autoneg. Switches are mostly HP Procurve if > that makes any difference. Interesting. I've got a ProCurve 2524 in our co-lo with tons of FreeBSD boxes hooked to it, all of which behave correctly via auto-neg. The FreeBSD boxes use a slew of NICs; em, fxp, and xl. The uplink port on our 2524 to our ISP, however, has to be set to 100/full on both ends (theirs and ours; theirs = Cisco, ours = HP) or else we end up with framing errors and other nonsense. For sake of comparison, I have sitting in my workroom a bge-based box hooked up to a ProCurve 2626 which behaves properly via auto-neg on both the 100mbit and the gigabit ports (I've tried both). I have not tried hard-setting them, since auto-neg seems to work. However, the instant I hook that box up to my Hawking non-managed gigabit switch (which is a switch where auto-neg has worked with every NIC I've tried until now), the switch and NIC auto-neg correctly to 1gb/full... except packets appear busted in some way: packets make it to the switch (one can see the LEDs blinking), yet the IP stack doesn't see anything in return. ARP also does not show anything. The fact that auto-neg is working, and that the switch indicates correct speed and duplex, makes me think this is some weird bge driver problem. Wiring is all CAT6, and obviously works fine with another switch. If I set `media 100baseTX mediaopt full-duplex` and reboot, everything works (at 100mbit of course) with that box. I'd love to give a kernel developer access to that box via serial console so they could debug what the heck is going on with auto-neg in that particular case. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
