Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: 2.4 delayed acks don't work, fixed | Date | Wed, 19 Mar 2003 01:35:23 +0300 (MSK) |
| |
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/
| |