lkml.org 
[lkml]   [1999]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch] TCP/IP delacks disabled with MPI
From
Date
Josip Loncaric <josip@icase.edu> writes:

> Andrea Arcangeli wrote:
> >
> > [...]
> >
> > One of the thing I noticed from the tcp traces sent to me from Josip, is
> > that currently we send the ack only if ATO expires or we received more
> > than 2*MSS data but we don't care about the exact _number_ of not acked
> > packets we have in the receive queue.
>
> My understanding is that Linux TCP incorrectly handles the slow start
> algorithm because it does not count the _number_ of packets that each
> ACK represents. This may be at the root of the problem we see, and
> perhaps explains why immediately ACKing every packet fixes the problem.
> Unfortunately, I cannot test 2.2.9 w/Andrea's patch because our system
> is now in use, and we've got to stick with 2.0.36 until at least
> September (for a variety of reasons).

Hmm? You must be thinking of a different slow start than everybody else.
Linux increases the cwnd by one for every received ack that acks some data.
Adding some packet counting heuristics is first impossible (the data may
have been repacketized since then in the write queue), slow (it would add
lots of cycles for list walking in the fast ack path) and experimental
(afaik nobody else does it this way, because it makes no sense - this is not
a research OS)

>
> BTW, rfc2414 suggests that the initial congestion window can be 3 or
> even 4, and that this is a good minimum value to use after being idle
> for a while. By default, TCP resets congestion window to 1 after being
> idle for an entire RTO. For our internal use only when TCP_NODELAY is
> set, we use exponential backoff to a minimum cong_window of 3, and
> various timeout constants are up to ten times lower (for faster
> recovery). Normal TCP operation is maintained for sockets without
> TCP_NODELAY.

It is of course ok to tune it to moderate values, Linux 2.2 didn't do it to
stay on the conservative side.
>
> Our Beowulf-class cluster has demonstrated that Linux TCP is simply not
> tuned for highly interactive interprocess communication. We need Fast
> Ethernet latencies well under 100 microseconds, 90+Mbit/s bandwidth, and
> responsiveness generally 10-1000 times better than what standard TCP
> uses need. Congestion on our switched fast ethernet network is very
> rare, and the sockets mostly behave as if direct full duplex crossover
> cables were used. Apart from the computational cost imposed by ACKing
> every packet, our modified TCP comes close to what we need. I hope that
> a better fix will become available, but in the near future we'd also
> like to try M-VIA which promises latencies about three times better than
> standard TCP.

Linux TCP tries to minimize acks for various reasons - perhaps you don't care
about low speed and congested links, but other people do.

Linux 2.2 has a few changes over 2.0 in this regard, e.g. it tries to match
its MSS estimate for the 2*MSS rule to the real world (this is mainly needed
for HIPPI where even bulk transfers can often be <MSS), it has a "quick ack
mode" to get the other end quickly out of slow start, and some other heuristics.
initial cwnd is still 1 per default, although it can be changed without
problems.

-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.133 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site