>Something interesting to note is that it is retransmitting
>every second or third packet, even though an ack was received.
No, look at the dump again. An ACK of 3072 means that the packet
ending in 3072 was received.
>If I can provide any other information that might help solve
>this problem, please ask -- this is very frustrating.
Ok. Let's start with some simple questions. What was the last
version that you got good ftp performance over your PPP line with?
[Both kerel and PPP driver #'s please]
How is performance in the other direction?
What do ping times look like?
What happens if you turn VJ compression off with PPP?
Also, if you want to mail me a tcpdump please include the start
of the FTP session as well. There is a lot of timing information I
can only figure out from the events at the start of a session.
>11:18:45.433760 ppp14-11.rns.1073 > atheist.ftp-data: . 2048:3072(1024) ack 1 win 31744
>11:18:45.433760 ppp14-11.rns.1073 > atheist.ftp-data: . 3072:4096(1024) ack 1 win 31744
>11:18:46.439040 atheist.ftp-data > ppp14-11.rns.1073: . ack 3072 win 4096
Hmm. Packet went out at 45.43, return at 46.43. Measured RTO is about 1
second from what I can see here.
>11:18:46.439040 ppp14-11.rns.1073 > atheist.ftp-data: P 4096:5120(1024) ack 1 win 31744
We send out our next packet since the window has opened up.
>11:18:48.010400 ppp14-11.rns.1073 > atheist.ftp-data: . 3072:4096(1024) ack 1 win 31744
We timeout and resend. We expected the ACK back by now. This indicates
that our current value for RTO is at about 2.57 seconds.
This is much longer than it should be.
>11:18:48.635040 atheist.ftp-data > ppp14-11.rns.1073: . ack 4096 win 4096
Ack actually arrives. About 3.2 seconds after the fact. Assuming the
pipe was empty when the two packets this went out with were sent,
and that you have a 14.4k modem, I'd guess the turn around should
have been something like 1.6 seconds. Still this is only .61 seconds
after then resend of the packet, so unless you have a 28.8 k modem,
this is almost certainly the packet ACKing the first copy of the data.
>11:18:48.635040 ppp14-11.rns.1073 > atheist.ftp-data: P 4096:5120(1024) ack 1 win 31744
Timeout on this packet. We waited about 2.19 seconds this time.
>11:18:49.240160 atheist.ftp-data > ppp14-11.rns.1073: . ack 5120 win 4096
ACK arrives, about 2.8 seconds after the send. This is still worse than
it should be. This time I'd have been expecting a bit over 1 second for
the real turn around time.
>11:18:49.240160 ppp14-11.rns.1073 > atheist.ftp-data: . 5120:6144(1024) ack 1 win 31744
>11:18:49.240160 ppp14-11.rns.1073 > atheist.ftp-data: . 6144:7168(1024) ack 1 win 31744
Ok, we were all caught up, so back to normal sending mode.
>11:18:50.235680 atheist.ftp-data > ppp14-11.rns.1073: . ack 6144 win 4096
First ACk comes in, takes a little under 1 second to arrive.
>11:18:50.235680 ppp14-11.rns.1073 > atheist.ftp-data: . 7168:8192(1024) ack 1 win 31744
Send next packet in response to ACK.
>11:18:51.836320 ppp14-11.rns.1073 > atheist.ftp-data: . 6144:7168(1024) ack 1 win 31744
Timeout, resend.
>11:18:52.646400 atheist.ftp-data > ppp14-11.rns.1073: . ack 7168 win 4096
Second ACK comes in, takes about 3.4 seconds. I expected closer
to 1.6 again.
And so on...
I don't see anything wrong here, except that the ACK packets are taking
much longer to get to us than I would have expected.
-- eric