On Wed, 10 Mar 2010 23:08:28 +0100 Andres Meyer <andres.meyer@xxxxxxxxxxxx> wrote: > On 10.03.2010 12:16, Roel van Meer wrote: > > I see. I couldn't see anything wrong in your dump, althoug I have to > > say I'm probably not proficient enough in interpreting tcpdump output > > to see whether or not something is amiss. > > > > Can you get the expected throughput with other applications apart from > > iperf? E.g. will scp or ftp give you more throughput or are those > > connections problematic as well? > > Thanks for the ideas. No, its the same with all tcp applications. I > tried netcat and wget. I also tried ethernet-in-ip (tap device with udp > transport, adjusted mtu to avoid fragmentation) just to hide the tcp > nature of the stream and exclude any too-intelligent-switch-type tcp RED > or similar. But in the end, it is probably not the problem of any > firewall if you can actually see the server respond with only 5-6 > packets for every ack and then wait for the next ack, even when the ack > expands the potential receiving tcp window all the time. > > I am really at a loss here. For me, it looks like if I would have set > the tcp window size of the server to 10k. But as you can see in the > /proc settings, I believe I did not. > > Any more thoughts? I am at a loss... TCP does slow start so it won't fill up window unless ack's come back. http://en.wikipedia.org/wiki/Slow-start If you have a bad TCP (like MacOS) or some crazy middlebox that delays the acknowledgments, then the window will increase much slower because the extended delay of the ack's would slow growth. The other possibility is that the receive window on the other side is too small. Both endpoints have to cooperate to allow for large amounts of in-flight data. -- 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
