>ack mode". See tcp_delack_estimator(). But the function tcp_remember_ack()
>seems to be messing things up for small packets. It tries to speed up
>pending acknowledgements when it sees PSH and small packets, but in so
>doing, erases the "quick ack mode" bit.
Agreed. I also don't like the HZ/50 fixed thing. Better to enter quickack
mode unconditionally when we get a tiny packet with PSH set. I am doing
that here.
Just for the record here the diff between my current tree and 2.2.2-pre2:
Index: tcp_input.c
===================================================================
RCS file: /var/cvs/linux/net/ipv4/tcp_input.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 tcp_input.c
--- tcp_input.c 1999/01/26 18:32:44 1.1.1.4
+++ tcp_input.c 1999/02/12 13:49:05
@@ -55,6 +55,11 @@
* work without delayed acks.
* Andi Kleen: Process packets with PSH set in the
* fast path.
+ * Andrea Arcangeli: Fixed a bug that was killing delayed
+ * acks completly because tp->ato was
+ * always 0 due a unluky iteraction
+ * between tcp_delack_estimator() and
+ * tcp_transmit_skb().
*/
#include <linux/config.h>
@@ -134,7 +139,7 @@
* Note: This also clears the "quick ack mode" bit.
*/
if(th->psh && (skb->len < (tp->mss_cache >> 1)))
- tp->ato = HZ/50;
+ tcp_enter_quickack_mode(tp);
}
/* Called to compute a smoothed rtt estimate. The data fed to this
I just know that Dave doesn't agree with this patch ;). But I don't like
HZ/50 because I don't like to erase the ato stat information. And I
also don't like to decrease the ato value.
To give a sense at the waiting we _must_ wait for a time we are _sure_ we
would get the second packet from the other end before timing out and so
acking unconditionally. If we simple wait a bit before acking, we are
_only_ decreasing performances without have a way to decrease the traffic
on the network.
For example waiting 20msec here is only a way to decrease performances. My
slowww link connection is not likely to get the second packet in 20msec.
Andrea Arcangeli
PS. the log has nothing to do with the patch, so don't get confused ;).
-
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/