> Indeed. Setting tcp_delack_min to 0 completely eliminated the undesiredWhat did it do to the packets per second or per unit of work? Depending on the nature of the race between the ACK returning from the remote and the application pushing more bytes into the socket, I'd think that setting the delayed ack timer to zero could result in more traffic on the network (those bare ACKs) than simply setting TCP_NODELAY at the source. And since with small packets and/or copy avoidance an ACK is (handwaving) just as many CPU cycles at either end as a data segment that also means a bump in CPU utilization. rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Alan Cox | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
