On Mon, 2015-02-02 at 13:25 -0800, Ben Greear wrote: > It is a big throughput win to have fewer TCP ack packets on > wireless since it is a half-duplex environment. Is there anything > we could improve so that we can have fewer acks and still get > good tcp stack behaviour? First apply TCP stretch ack fixes to the sender. There is no way to get good performance if the sender does not handle stretch ack. d6b1a8a92a14 tcp: fix timing issue in CUBIC slope calculation 9cd981dcf174 tcp: fix stretch ACK bugs in CUBIC c22bdca94782 tcp: fix stretch ACK bugs in Reno 814d488c6126 tcp: fix the timid additive increase on stretch ACKs e73ebb0881ea tcp: stretch ACK fixes prep Then, make sure you do not throttle ACK too long, especially if you hope to get Gbit line rate on a 4 ms RTT flow. GRO does not mean : send one ACK every ms, or after 3ms delay... It is literally : aggregate X packets at receive, and send the ACK asap. If the receiver expects to have 64 ACK packets in the TX ring buffer to actually send them (wifi aggregation), then you certainly do not want to compress ACK too much. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
