[4301] in linux-net channel archive
Re: bad PPP Performance (with and without IRQTUNE)
daemon@ATHENA.MIT.EDU (Paul Mackerras)
Thu Sep 5 15:15:33 1996
Date: Thu, 5 Sep 1996 16:14:58 +1000
From: Paul Mackerras <paulus@cs.anu.edu.au>
To: neuffer@kyle.i-connect.net, linux-net@vger.rutgers.edu,
linux-ppp@vger.rutgers.edu
Reply-to: Paul.Mackerras@cs.anu.edu.au
Simon someone wrote (forwarded by Michael Neuffer
<neuffer@goofy.zdv.uni-mainz.de>):
> I am suffering (among other things) from a horrendously slow PPP performance.
(stuff deleted)
> PPP is on either Motorola BitSRFR PRO (115,200 on one B channel) or a new USR
> Sportster ``33.6 capable'', again, at 115,200.
(more)
> Running PPP (pppd 2.2.0f) disconnects two/three times upon dialup from
> either line. Once connection is established, performance is horrendous.
> Typically ftp will do 800 bytes/sec on the ISDN line. Less on the
> modem.
>
> When downloading a file, one can observe the receive LED on the modem/NT
> to glow steady and bright with a blip in the other direction every 5
> seconds or less. If you abort a transfer, the line remains active for
> 20-30 seconds (way too long).
This sounds very much like symptoms I've often seen on PPP links. The
problem seems to be that the sender is retransmitting an awful lot (as
indicated by netstat -s on most systems except linux), not that PPP is
dropping or corrupting packets. I don't know exactly why the sender
should be retransmitting so much, but reducing the mru to 552 or even
296 helps a lot.
I suspect the problem occurs when you get a lot of buffering in the
link, as you can do with fast modems. The first few packets will get
acked very quickly, so the sender's TCP's round-trip-time estimate is
fairly low. Subsequent packets take longer and longer before
they actually go out over the line, and thus the round-trip time
increases. At some point the round-trip time exceeds the sender's
retransmission timeout and you start getting lots of retransmissions.
(This is mostly speculation :-)
Paul.
