On Tue, Mar 18, 2003 at 11:13:42PM +0300, kuznet@ms2.inr.ac.ru 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
instead.
>
> 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?
Andrea
-
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/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:24 EST