On Tue, 21 May 2013 19:24:24 +0100 Sam Crawford <samcrawf...@gmail.com> wrote: > To be clear, this doesn't just affect this one hosting provider - it seems > to be common to all of our boxes. The issue only occurs when the sender is > connected at 1Gbps, the RTT is reasonably high (> ~60ms), and we use TCP. > > By posting here I'm certainly not trying to suggest that the e1000e driver > is at fault... I'm just running out of ideas and could really use some > expert suggestions on where to look next!
I think you're overwhelming some intermediate buffers with send data before they can drain, due to the burst send nature of TCP when combined with TSO. This is akin to bufferbloat. Try turning off TSO using ethtool. This will restore the native feedback mechanisms of TCP. You may also want to reduce or eliminate the send side qdisc queueing (the default is 1000, but you probably need a lot less), but I don't think it will help as much. ethtool -K ethx tso off gso off you may even want to turn GRO off at both ends, as GRO will be messing with your feedback as well. ethtool -K ethx gro off I'm a bit surprised that this issue isn't being understood natively by the linux stack. That said GRO and TSO are really focused on LAN traffic, not WAN. Jesse ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
