[lkml]   [2003]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4 delayed acks don't work, fixed
On Tue, Mar 18, 2003 at 11:13:42PM +0300, wrote:
> Hello!
> > what is the point of this:
> >
> > #define TCP_DELACK_MAX ((unsigned)(HZ/5)) /* maximal time to delay before sending an ACK */
> It is maximal delack for generic (transactional) traffic. It is not used
> in stream mode. Big clamp of 500msec is hardwired to tcp_send_delayed_ack,
> I simply was not able to invent name for it.
> > and finally by the delack timer (if it was set to 1):
> It is the place. Session stops to be tranasaction, when we
> experience the first delack timeout.

In a normal internet connection you will always get packet loss or
timeouts in the middle of any big transfer.

however as far as the delacks can be reactivated w/o waiting dozen of
packets it's ok.

> > tcp_enter_quickack_mode is called every time we have to disable delayed
> > acks like when we send duplicate acks or when there's packet reordering
> > or whatever similar error.
> Also correct. Delacks are disabled while recovery periods.

sure, delacks must be disabled until the ofo queue is empty again.

> > how can 'pingpong' relate to the direction of the stream? I see no
> > relation at all.
> It is set, when we see traffic in both directions. It is cleared
> when we see the first delack timeout. Logically, it should be cleared
> when we do not see data flowing in opposite direction for some time,
> but as soon as we do not see delack timeouts, it does not matter.
> > since it's never re-activated,
> If you do not see any delack timeouts, clearing pingpong does not make
> difference.

I see seldom delack timeouts during streming because the streamer simply
waits, the bandwidth of the link is higher than the streamer one

> > this is only true if pingpong was just 0. but if pingpong is 0 it won't
> > send delayed acks in the first place because quick will very rarely get
> > down to 0.
> Stop here. quick quickly must become zero. In your case, when window
> is one packet, it happens exactly after the first packet.

there must be something that forbids it because I get immediate acks

> I am confused. Please, check.
> > segments there SHOULD be an ACK for at least every second
> > segment.
> SHOULD, not MUST. :-)
> Jokes apart, it is simply wrong statement. Right one reads: "when right
> egde of window advanced by at least two segments". It is supposed to provide
> ACK clock, but when window stalled, such acks are pure abuse, they are simply
> ignored by clocking mechanism.
> > if (eaten) {
> > if (tcp_in_quickack_mode(tp)) {
> > tcp_send_ack(sk);
> > } else {
> > tcp_send_delayed_ack(sk);
> > }
> >
> > it's not checking if more than one segment arrived.
> "eaten" is special path, it happens when this function is subroutine
> of tcp_recvmsg(), where the same code is executed upon return
> from the function.

so is the ack sent elsewhere if this was the third packet and there's a
window advance?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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