From owner-freebsd-hardware Mon Sep 16 19:03:21 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA28123 for hardware-outgoing; Mon, 16 Sep 1996 19:03:21 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA28108; Mon, 16 Sep 1996 19:03:16 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA03421; Mon, 16 Sep 1996 19:02:04 -0700 From: Terry Lambert Message-Id: <199609170202.TAA03421@phaeton.artisoft.com> Subject: Re: Slow Etherlink To: jab@rock.anchorage.net (Jeffrey Barber) Date: Mon, 16 Sep 1996 19:02:04 -0700 (MST) Cc: freebsd-hardware@FreeBSD.org, hackers@FreeBSD.org In-Reply-To: <01BBA3DF.D5124740@jabpc.rtfm.com> from "Jeffrey Barber" at Sep 16, 96 03:00:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > OK, If we can get past all the sarcasim bull shit! I realize that the = > ping I showed for Linux seems to be slower than FreeBSD but the point is = > that I have faster telnet response from Linux than I do FreeBSD. For the = > more serious ppl who want to help. Let me rephrase my question: Why = > would pinging and telneting to FreeBSD be slower than that of a Linux = > box? It shouldn't be. By "slower", do you mean: 1) Slower to make a TCP connection for Telnet? a) Check your rarp setup b) Check your DNS setup c) Check your hosts file d) Back off a version or two of BIND e) Back off a version of sendmail, or reset the sendmail option to prevent it verifying source addresses 2) Slower to fail in the no route to host case? a) Yes, this is because FreeBSD retries rather than giving up. For transient initial loss, this seems slower. The fix is to correct your circuit so you don't get transientinitial loss. b) In the case of a transient failure, the BSD behaviour will not lose the connection, where the Linux will. 3) Slower to respond to pings? a) This could be your source host b) Check your TCP extensions. If you have a bogus TCP/IP implementation that doesn't understand RFC 1323 or RFC 1644, or can't correctly ignore them if they are used, then you should turn them off. 4) Slower to start pinging? a) There is an option that controls "time to live" on packets. Man sysctl. > bash$ ifconfig -a > > lp0: flags=3D8810 mtu 1500 > ep0: flags=3D863 mtu 1500 > inet 19.51.13.1 netmask 0xffffff00 broadcast 19.51.13.255 > > I have never seen the SIMPLEX entries before on other OS's. Can this be = > the problem or no? I have a 3com Etherlink III isa card installed the = > FreeBSD system of which I had in a Linux box previously. It means it can't transmit and receive at the same time. This is a card "feature", and if you haven't seen it before, your other OS has been lying to you (or it's one of the drivers that needs updated). In general, SIMPLEX, if capable of being fixed via a driver interface (usually it is not, as noted above), will only affect unidirectional throughput, generally out of the machine, and generally only for real data transferred (ie: it's not your "ping" problem, whatever your "ping" problem is -- you haven't supplied enough information for us to know). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.