Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Sep 1996 19:02:04 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        jab@rock.anchorage.net (Jeffrey Barber)
Cc:        freebsd-hardware@FreeBSD.org, hackers@FreeBSD.org
Subject:   Re: Slow Etherlink
Message-ID:  <199609170202.TAA03421@phaeton.artisoft.com>
In-Reply-To: <01BBA3DF.D5124740@jabpc.rtfm.com> from "Jeffrey Barber" at Sep 16, 96 03:00:41 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
> ep0: flags=3D863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609170202.TAA03421>