Messages in this thread | | | Date | Sat, 30 Mar 1996 20:10:49 +0200 (EET) | From | Linus Torvalds <> | Subject | Re: 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
| |