On 11/10/2013 11:11 AM, Youssef Bengelloun-Zahr wrote: >>> - TCP traffic reaches up to 90 Mbits/s for one way streams (both >>> ways), >>> >>> - TCP traffic hits some kind of limit and isn't able to achieve more >>> than 40-60 Mbits/s in average <=== That's the problem we are facing
If you are trying to saturate the link in both directions each of the acknowledge packets will compete against the other stream and will have a hard time reaching back. If the device has too small buffers, the ACKs for stream 1 may be dropped, which may cause retransmits in stream 1, aggravating the problem for session 2, which will retransmit too, further aggravating the problem for stream 1. If the device has too large buffers, the BW*DLY product of the link will increase a bit which will lower the performance of the TCP session. A good balance must be found. Try controlling your tests and see if you can reduce the max BW per session. See how far you can go. I'd try tweaking the buffers and repeating. Also, as a measure, ping to the other end and measure RTT. Now, with both sessions open, repeat the RTT measurement. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
