> 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