Date: Sun, 4 Nov 2001 00:54:13 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: <Master589095296@aol.com>, <freebsd-questions@FreeBSD.ORG> Subject: RE: Problem with 100mbit lan running <16KB/sec file xfers Message-ID: <002d01c1650e$46e8e460$1401a8c0@tedm.placo.com> In-Reply-To: <11f.6aa9f9e.29164760@aol.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message----- From: owner-freebsd-questions@FreeBSD.ORG [mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Master589095296@aol.com Sent: Saturday, November 03, 2001 11:25 PM To: freebsd-questions@FreeBSD.ORG Subject: Problem with 100mbit lan running <16KB/sec file xfers > I am having a problem with FreeBSD4.4-STABLE-10.29.2001 network performance. I am > using Netgear FA-312 network adapters in all machines with a NDC Communications > NSH510 5 port switch. Three machines are running FreeBSD. All FreeBSD machines are > running the same version. There are two Windows computers running Win98SE. All > network connections are 100mbit full-duplex as stated by ifconfig and windows and > the switch. > Problem: FTP or NFS file transfers between any of the three FBSD machines with file > sizes say >60KB, the connection slows to a crawl and stops. FTP file transfers > between the Win98 machines and FBSD machines have the same problem. But, using file > transfers between the two Win98 machines, file transfer throughput is in the 10-12 > MegaByte/sec range. HEL LO! Do the math please - you just stated that the Windows systems file transfer throughput is in the 10-12 MegaByte/sec range, this is 80-100Mbt/Sec. That's HALF-DUPLEX 100Mbt!! If the Windows systems really were in full-duplex mode you should see 25 MegaByte/sec. Just because the Windows systems claim that they are in full duplex doesen't mean bullshit. Device drivers can lie and tell you what you want to read. > Note that I did not start having this problem before I upgraded > the FBSD machines to 4.4-STABLE from 4.2STABLE. Next mistake! Please read the manual and learn what the difference between STABLE, RELEASE and CURRENT is. STABLE IS NOT RELEASE! I'll reprint here from http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html "...This is still a development branch, however, and this means that at any given time, the sources for FreeBSD-STABLE may or may not be suitable for any particular purpose. It is simply another engineering development track, NOT A RESOURCE FOR END-USERS..." (capitalization I added) DO NOT submit bugs written up this way to GNAT from a STABLE load!!! Submit from RELEASE. If your submitting from CURRENT or STABLE it's expected that you know what your doing and can submit both the bug and the fix. Your problem MAY NOT BE OCCURING in any of the RELEASES. In short, if you can't solve this kind of problem yourself you should NOT be messing with STABLE. > I have submitted a bug report to GNATS, but it was closed stating that it is a > config problem between the NICs and the switch on my end. It most likely is. > How can it be a config problem on my end when the only thing that has changed is > the software load on the FBSD machines? Also, if the config theory is true, then > how does one account for the fact that the Windows machines don't have this problem? > I have even rotated cables and ports and the problem stays with the three FBSD > machines. The only fix that I have found so far is to set the network adapters to > half-duplex mode. Any suggestions before I resubmit a GNATS problem report? I'm assuming that your using the sis driver. For the sake of the following example, I'll assume that the problem IS indeed present in FreeBSD 4.3 RELEASE and IS NOT indeed present in FreeBSD 4.2 RELEASE. But, before you submit a report you need to verify this yourself!!! Diffing the sis driver in 4.2RELEASE against 4.3RELEASE (4.4RELEASE and 4.3RELEASE use the same driver) shows that in the 4.3 driver there is a good chunk of additional code added in in several sections. However, the only section that appears to affect your particular cards is the following in if_sis.c : 670,679d596 < < /* < * If this is a NetSemi chip, make sure to clear < * PME mode. < */ < if (sc->sis_type == SIS_TYPE_83815) { < CSR_WRITE_4(sc, NS_CLKRUN, NS_CLKRUN_PMESTS); < CSR_WRITE_4(sc, NS_CLKRUN, 0); < } < Now, I have no idea what PME mode is or why the later driver has this additional check and command in it, but none of the other changes appear to have anything to do with your chipset, but rather the SiS 630E chip and a bunch of stuff with the pci bridge (which if that was busted your card wouldn't work at all I'd guess) But, my guess is that without PME mode that under the old driver that your cards were not, actually, going into real full-duplex. The new driver IS switching on full duplex, and that the NDC Communications hub is blowing up on real full-duplex. You CAN if you want, comment this section out of the driver in your system, rebuild the kernel, and power-cycle your system and the hub and see if the problem goes away. It might be interesting results. Borrow someone else's switching hub (it must be manufactured by a different vendor than NDC Communications) and test with that. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002d01c1650e$46e8e460$1401a8c0>