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...
Cheers,
Andres
--
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
