Date: Thu, 4 Mar 1999 08:09:01 +0100 From: Andreas Klemm <andreas@klemm.gtn.com> To: dillon@FreeBSD.ORG, eivind@FreeBSD.ORG, archie@FreeBSD.ORG, peter@FreeBSD.ORG, semenu@FreeBSD.ORG, jkoshy@FreeBSD.ORG, dfr@FreeBSD.ORG, gibbs@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: to every person, who committed things to the tx driver, which shows strange behaviour Message-ID: <19990304080901.A777@titan.klemm.gtn.com>
next in thread | raw e-mail | index | archive | help
Hi, I'm writing this to every person, who committed stuff to the tx driver, possibly somebody has an idea, what's still wrong with the driver, especially in 2.2.8-STABLE or what race condition might occur. Stefan Esser made this suggestion, after a large debugging session via phone. The symptoms are, slow incoming performance (not more than 860 KByte/sec), dog slow (80 KByte/sec) outgoing performance, when doing a put (ftp) or when clients read data via ftp/http). Any combination of 10 / 100 MBit full or half duplex doesn't change the strange behaviour, that the card has absolutely no good performance, sending packets out. The machine sits behind a Catalyst 5500 switch. The Catalyst switch has a peak load of about 10%, not more in the last weeks, so it's not the switch. The FreeBSD machine isn't loaded as well. To make sure, that it's not the cabling or the switch, I connected my laptop to the FreeBSD machine directly with a crossover cable. When doing a ftp session I don't get more than 27 KByte/sec. The connection seemed to hang. System: HP Kayak XA, 450 MHz Pentium II, 128 MB RAM AHA 2940, SMC PCI Network Card, ELSA PCI Grafic Card I made sure with dmesg | grep irq, that the SMC card has an irq of it's own. It's IRQ 10 now. At the very beginning of the debugging session we experienced the following extra problems, enabling #define EPIC_DEBUG 1 cured these problems: 1) When reading data from the apache webserver, the first two seeconds I see, that the card is processing up to 1000 interrupts per second (saw this via systat -vmstat 1) When doing a netstat -I tx0 1 you see, that 2 seconds long the card is sending many packets per second (around 20 or 40 KByte) but after the 2 seconds the card sends and receives only about 1-2 packages per seconds 2) During boot the driver sends a message, that he can't read PHY! 3) Doing a while true do ifconfig -a | grep status: done shows, that the card changes status When compiling a kernel without EPIC_DEBUG, PHY! isn't recognized and the card doesn't get status connected, instead of this it flaps between to different messages (sorry forgot about it) After defining EPIC_DEBUG the tx0 driver recognizes PHY! and status: changes to "connected". Without EPIC_DEBUG telnet sessions with lot's of output (ls -l in a long directory) tend to slow down dramatically after 2 seconds, then hang up to session losses. Within this insane state I only got 27 KByte/sec. throughput from a client getting the kernel via ftp. With EPIC_DEBUG the tcp output performance increased to 86 KByte/sec. Now the transfers doesn't hang, telnet sessions doesn't hang anymore. Everything is fine with the exception, that I only get 86 KByte/sec throughput out and only 860 KByte/sec. in on a 450 MHz PII machine being connected to a Cisco Catalyst switch in 100 MBit full duplex mode. I set this explicitely on the switch and on the FreeBSD machine, since auto recognition doesn't work well. BTW: netstat -i didn't show any collisions or such (shouldn't appear on a switch port in full-duplex mode). The catalyst switch has IOS 4.4(1) on it and is otherwise running fine. It's the switch for our floor in the building ... and as I said, the load isn'r really heavy and I still had the problem around 7pm, when not many people are in the building ... Well, what's that ???? Any idea ??? BTW, when using the tx driver from 2.2.7 in a 2.2.8-STABLE kernel (without this debugging define) the machine hangs during boot, but the tx0 driver recognized PHY! as I could see on the console. This is only the case with the FBSD 228 version of the tx driver AND enabling EPIC_DEBUG Could you figure out, what's going wrong so badly ??? Did ever somebody test the driver in high performance machines on 10 or 100 MBit networks ???? Am I the only person having this trouble ??? Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990304080901.A777>