lkml.org 
[lkml]   [2003]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.4 delayed acks don't work, fixed
Date
Hello!

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

We do the best efforts to disable them until sender completes slow start
i.e. half of advertised window.

Again, this does not matter in your case, you have window of one (rarely, two)
packets though all the tcpdump. And this bothers me a lot, much more than
ack frequency.


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

I do not understand this, to be honest. What does clock this sender?
Some internal clock of sender?

If it is clocked not by acks, and its clock is slower than ack clock,
then I daresay we do absolutely right thing (modulo funny window).



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

Adding to:

> > I am confused. Please, check.

... it is the thing to understand. I still do not.


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

It is sent when cleanup_rbuf() is called, this happens when the function
returns and no more skbs are _already_ queued in backlog. Until that time
it does not make sense to send ACKs. On tcpdump you would see it as burst
of ACKs, spaced by microsecond intervals.

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

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