Date: Fri, 3 Oct 1997 15:20:16 +0930 From: Greg Lehey <grog@lemis.com> To: Dave Hummel <hummel@www.buffalostate.edu> Cc: questions@FreeBSD.ORG Subject: Re: slow telnet Message-ID: <19971003152016.24243@lemis.com> In-Reply-To: <Pine.LNX.3.95.971002125333.2256A-100000@www.buffalostate.edu>; from Dave Hummel on Thu, Oct 02, 1997 at 01:29:00PM -0400 References: <Pine.LNX.3.95.971002125333.2256A-100000@www.buffalostate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 02, 1997 at 01:29:00PM -0400, Dave Hummel wrote:
> Hi,
>
> I'm connected to the internet at 14.4. Yes, I know this is extremely slow.
> The thing is, it seems like wu-ftp and apache are very responsive to
> outside connections. The problem is that telnet is very slow coming in or
> going out. Connections are from/to Red Hat Linux, Digital Unix, VMS and
> NT. I really don't expect high performance because of obvious things like
> crappy old phone lines etc. There does seem to be some disparity, however,
> between the performance of telnet as opposed to ftp and http all things
> condidered.
>
> I can live with some key lag, but I often have to wait five or more
> seconds for any response at the other end. I have disabled tcp_extensions
> which is about the only piece of advice I could find in the mailing lists,
> and network traffic to my machine is pretty much null.
That is, of course, ridiculously slow, even for a 2400 bps link. The
problem must lie elsewhere.
> _Any_ advice on what else to do about this will be appreciated even if
> it's "you can't do anything" or "get a better connection". If, however,
> there is a configuration trick or two that I'm ignorant of, this is even
> better :) - Just give me a hint on where to start looking.
OK. First, are you sure that it's not the other end? Since you've
tried multiple systems, it probably isn't.
Next, find out what's going on. Use tcpdump to watch the packets
going across and back. You should see something like this, which is a
telnet session between the systems freebie and yana:
# tcpdump host yana
tcpdump: listening on ep0
Make sure you get the correct interface. If you don't, specify it
with the -i option.
15:03:02.529150 freebie.lemis.com.1041 > yana.lemis.com.telnet: S 1814815854:1814815854(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) [tos 0x10]
15:03:02.530064 yana.lemis.com.telnet > freebie.lemis.com.1041: S 2966477972:2966477972(0) ack 1814815855 win 17280 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
15:03:02.530296 freebie.lemis.com.1041 > yana.lemis.com.telnet: . ack 1 win 17280 <nop,nop,timestamp 19007 2233592,nop,nop,[|tcp]> (DF) [tos 0x10]
15:03:02.536769 freebie.lemis.com.1041 > yana.lemis.com.telnet: P 1:28(27) ack 1 win 17280 <nop,nop,timestamp 19007 2233592,nop,nop,[|tcp]> (DF) [tos 0x10]
15:03:02.633911 yana.lemis.com.telnet > freebie.lemis.com.1041: . ack 28 win 17253 <nop,nop,timestamp 2233592 19007,nop,nop,[|tcp]> (DF)
15:03:03.073553 yana.lemis.com.1590 > freebie.lemis.com.domain: 54674+ (46)
15:03:03.074802 freebie.lemis.com.domain > yana.lemis.com.1590: 54674* 1/3/3 (214)
15:03:03.111857 yana.lemis.com.telnet > freebie.lemis.com.1041: P 1:16(15) ack 28 win 17253 <nop,nop,timestamp 2233593 19007,nop,nop,[|tcp]> (DF) [tos 0x10]
... setup
The following is what goes across the net when I type in the
characters 'ps':
15:04:14.006297 freebie.lemis.com.1041 > yana.lemis.com.telnet: P 348:349(1) ack 932 win 17280 <nop,nop,timestamp 191502233639,nop,nop,[|tcp]> (DF) [tos 0x10]
Packet sent across (character 'p')
15:04:14.009085 yana.lemis.com.telnet > freebie.lemis.com.1041: P 932:933(1) ack 349 win 17280 <nop,nop,timestamp 2233735 19150,nop,nop,[|tcp]> (DF) [tos 0x10]
yana echoes the packet and acknowledges the incoming packet after 2.7
ms. On your link, expect a minimum of about 250 ms.
15:04:14.138962 freebie.lemis.com.1041 > yana.lemis.com.telnet: . ack 933 win 17280 <nop,nop,timestamp 19150 2233735,nop,nop,[|tcp]> (DF) [tos 0x10]
freebie acknowledges the echo packet after a short delay. This won't
show up in a steady stream of traffic.
Then we have the next character:
15:04:14.512173 freebie.lemis.com.1041 > yana.lemis.com.telnet: P 349:350(1) ack 933 win 17280 <nop,nop,timestamp 19151 2233735,nop,nop,[|tcp]> (DF) [tos 0x10]
15:04:14.513821 yana.lemis.com.telnet > freebie.lemis.com.1041: P 933:934(1) ack 350 win 17280 <nop,nop,timestamp 2233736 19151,nop,nop,[|tcp]> (DF) [tos 0x10]
15:04:14.538426 freebie.lemis.com.1041 > yana.lemis.com.telnet: . ack 934 win 17280 <nop,nop,timestamp 19151 2233736,nop,nop,[|tcp]> (DF) [tos 0x10]
When you try it, you'll probably see something different.
Possibilities are:
1. There will be a much longer delay on the echo than the 250 ms that
you'd expect from the speed of the link. 1 second is definitely
too long, for example.
2. More likely, you'll see TCP retrying. You'll see the same
sequence numbers going across, for example the "P 348:349" in the
first packet of the triplet, or the "P 933:934" in the reply from
yana. This is an indication that something isn't getting through.
3. Possibly you'll see something else.
I'm currently writing a chapter about network debugging for the second
edition of "The Complete FreeBSD", so if you have an interesting one,
and you're willing, I'd like to include it in the book. Please let me
know.
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971003152016.24243>