Messages in this thread | | | Date | Thu, 11 Apr 1996 09:08:28 +0100 (BST) | From | Steve Davies <> | Subject | Re: Fix for SLOW PPP Bug |
| |
On Wed, 10 Apr 1996, Linus Torvalds wrote:
> Umm.. I've been looking at the use of "tcp_reset_xmit_timer()", and it may be > that we're seeing a timer fight between the delayed acks and retransmissions, > where both want to use the same timer and they don't like each other messing > with it.. > I can certainly imagine a couple of scenarios where one use of the timer wants it to timeout now, and the other then sets a long delay, but I don't know whether my thoughts match reality.
Is it worth introducing an independent ack-timer ?
> if (!sk->delay_acks || th->fin) { > tcp_send_ack(... > } > else > { > ...
I spotted this too. My change is a little different to yours, and while I'm not sure how valid it actually is, I believe it does essentially the same thing as the one you posted (which I haven't had a chance to try)
if (!sk->delay_acks || th->fin || sk->ack_backlog) { tcp_send_ack(sk); } else { ...
> I'd suggest changing the "if" case to something like this: > > if (!sk->delay_acks || th->fin || > sk->bytes_rcv > sk->max_unacked || > sk->ato > HZ/2 || > tcp_raise_window(sk)) { > tcp_send_ack(... > } > else > { > > (That is essentially what 1.3.72 uses, and while I don't particularly like the > extra cases it might help to be overly cautious in this case..) >
I tried my patch on a clean 1.3.86 kernel, and got the following results:
1.3.86 1.3.86+
NNTP slurp 3.5Kb/s 3.8Kb/s FTP compressible 6.1Kb/s 6.4Kb/s
The figures above are averages over a period of repeated re-runs of each transfer. The figures are starting to look good now, but I still want to improve my nntp transfers to nearer 5Kb/s which I can attain under Windows - I imagine this is an application difference though.
Any comments ? Steve
| |