On Wed, 26 Mar 2008, Pavel Georgiev wrote: > I have several linux boxes hooked to a gigabit switch and accidentally noticed > that tcpdump reports packages with size larger than 1500: > > tcpdump greater 1600 -n > > This produces many lines of output with packets with size > 1500 (2960, 4420, > etc.) > > The MTU of the interface is 1500 (reported by ifconfig), the MTU on the other > boxes hooked to the same switch is also 1500. > > This would be OK if it was limited to the intranet only (although strange as > the MTU is 1500 on all boxes), but this also happens for packets going out to > the Internet. I traced a tcp connection to an outside host on both sides and > notices that both hosts send an mss of 1460 during connection initialization, > but the first packet (and all other) that the box in question sends is with > length 2960, which on the other side is received and acknowledged as two > packets with length 1500. This suggest that someone on the way (probably the > first router) does fragmentation, which is OK. The problem is that eventually > packets on the remote host start to arrive with changed order, which tcp > handles as expected, but this somehow prevents the tcp window from growing > and as a result the transfer rate never gets high enough to utilize the line. > > What I`m trying to find out is how come packets leaving my box have larger > size than the MTU of interface (I`m guessing that if I solve that, no > additional fragmentation will occur, packets will arrive in the right order > and tcp windows will grow as expected). > > Few notes: > - kernel on the boxes in question: 2.6.14.6 and 2.6.15 > - the line to the boxes is wide enough to handle 100Mbit/s, if I try the same > test that I describe but in the other direction, I get the full 100Mbit/s > speed as tcp window grows high enough to allow this even with latency > > 100ms. > - boxes in question use e1000 driver. Perhaps try disabling TSO on the interface with ethtool. -Bill -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html