lkml.org 
[lkml]   [1996]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Slow PPP - caused by duplicate packets?


On Sat, 30 Mar 1996, David Monro wrote:
>
> My PPP link has been suffering the dreaded slowness, particularaly if I talk to
> the Solaris box which is the main server at the remote end. My ppp server is a
> NetBSD/sun3 machine; the remote modem is on a cisco terminal server from which
> I rlogin to the netbsd box. I use an mtu of 1500.
>
> Looking at the modem traffic while using 'more' on a large file with a 80x60
> xterm, I noticed that packets seemed to be still coming down the link after I
> had got to the end of one page, but before a started the next one. It would
> only happen for a second or so after the end of the page.
>
> So I grabbed tcpdump and had a look at the packets, and there seem to be
> duplicate packets on my link! At the end of this mail, you will find the
> tcpdump output for one screenful of text. staff is the remote server machine,
> running Solaris 2.5. Fuzzbox is the local Linux box, running 1.3.79.

Umm.. The tcpdump info you include would seem to indicate that linux is
doing everything correctly, and that the Solaris box is doing something
stupid.

However, I can't imagine that Solaris started doing stupid things for
everybody in the 1.3.7x timeframe and worked fine before that, so there
must be something we're not seeing here. Does anybody have access to
tcpdump at the _other_ end?

It _looks_ like the other end is ignoring our first ACK, so it times out,
and then sends the packet again. And then we ACK it twice (that's normal
linux behaviour - there's the "normal" ACK, and then there is an extra
one that comes from the fact that the linux TCP code decides we'd better
ack again when we got a packet re-sent).

Now, WHY is Solaris ignoring our first ACK?

> I don't know a great deal about tcp, but I am sure this shouldn't be happening!

Indeed.

> fuzzbox:~ # /usr/local/sbin/tcpdump -S -i ppp0
> tcpdump: listening on ppp0
> 12:05:38.477293 fuzzbox.1023 > staff.login: P 1267692566:1267692567(1) ack 229386462 win 29417 (DF) [tos 0x10]
> 12:05:38.747298 staff.login > fuzzbox.1023: P 229386462:229386484(22) ack 1267692567 win 8760 (DF)
> 12:05:39.057303 fuzzbox.1023 > staff.login: . ack 229386484 win 29395 [tos 0x10]
> 12:05:41.087341 staff.login > fuzzbox.1023: P 229386484:229387935(1451) ack 1267692567 win 8760 (DF)
> 12:05:41.387346 fuzzbox.1023 > staff.login: . ack 229387935 win 29404 [tos 0x10]

This is a perfectly fine ACK, but..

> 12:05:42.627369 staff.login > fuzzbox.1023: . 229386484:229387935(1451) ack 1267692567 win 8760 (DF)
> 12:05:42.627369 fuzzbox.1023 > staff.login: . ack 229387935 win 29404 [tos 0x10]
> 12:05:42.927375 fuzzbox.1023 > staff.login: . ack 229387935 win 29404 [tos 0x10]

..for some reason staff decides to ignore it and resends.

Alan, any ideas? The other end would be perfectly right in ignoring our
packets if they get sent out with the wrong checksum, for example. Or
maybe the compression code (both cslip and ppp use the same code, no?)
has problems and "compresses" the packets to something unrecognizable?

This does not look like a interrupt latency problem: we seem to be
receiving the packets ok. We might not be sending them out ok (tcpdump
shows only what the net layer _thinks_ is happening, and there is no
guarantee that the packets leave the computer looking ok), but that
shouldn't be affected by interrupt latency (the worst that could happen
is that send side throughput isn't optimal, but if we're receiving 1.5kB
packets ok then it can't be noticeable).

Hmm.. Another possibility is that the delayed ACK code is subtly broken,
and that Solaris has started re-transmitting the packet before it
actually got our ACK for it (there is a 2-second gap between us sending
the ACK and the Solaris re-sending, but it might have taken 2 seconds to
send a 1451-byte packet on a slow link).

David, there are a few places where sk->ato is initialized to something
like "HZ/3", change those to 0, and see if that helps? Just search for them
with

grep "ato *=[^=]" *.c

in linux/net/ipv4 (two in tcp_input.c and one in af_inet.c, it seems).

Linus


\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.052 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site