lkml.org 
[lkml]   [1999]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] TCP/IP delacks disabled with MPI
On Mon, May 24, 1999 at 04:48:19PM +0200, Andrea Arcangeli wrote:
> On 23 May 1999, Andi Kleen wrote:
>
> >Slow start is such a critical thing to avoid internet meltdown, and with Linux
> >becoming more and more popular we really cannot risk any experiments in release
> >kernels here.
>
> Agreed.
>
> >The problem is at the sender: it doesn't send enough acks. Linux 2.2
>
> I think the problem is the _receiver_ that is not sending the ack until
> the ato expired if the sender is in slow-start for example. I think this
> happens because we don't force an ack at the second frame received as
> rfc1122 seems to state. As side effect we are also not opening fast enough
> the cwnd on the sender side.

Ooops, of course I meant to write recever, not sender @)
Your paragraph says what I meant to write. So I think we agree on the cause
of the problems.

>
> I think that this is the reason that MPI people got boosted by disabling
> completly delayed acks (no need to wait ato to timeout anymore and cwnd
> increase at an higer rate). Now I think that if delayed acks would work
> right they woldn't need to disable them to get performances.

Agreed.

>
> I had not yet feedback about my last patch (the one I sent yesterday with
> the line of credits), to know if such patch works well as disabling
> delacks completly while using MPI though, so I am not sure yet if my
> theory has something to do with reality :-).

I did a patch now to handle extend quick ack mode to more packets. Let me test
it a bit more here, then we can try if it helps for the benchmarks.

One problem is the interaction between quick acks and fast retransmit. 2.2 enables
quick ack mode as soon as a OOO packet is received, under the assumption that the
sender is in slow start now. With fast retransmit this is not true, but because
it only accelerates a single ack and the next received packet in a fast retrans
situation is usually OOO too (and would have cause a fast ack anyways) it doesn't matter.
With multiple quickacks it is differently, sending many acks too quickly after fast
retrans could disturb the ack clock. I have to think a bit more about the best solution
here.


-Andi

--
This is like TV. I don't like TV.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.685 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site