Each frame goes through several buffers as you send it: The application buffer, The Protocol Buffer, The Software interface buffer and the Hardware interface buffer. As you start stressing the stack by sending high speed data you will fill up these buffers and either block or lose data. You also have strategies for timeliness and polling that can impact your performance. For example, by using a larger buffer and poll less often you can get much better performance while sacrificing latency.
TCP is optimized for high speed bulk transfers while UDP is optimized for low latency in the Linux kernel. This has an impact on buffer sizes and how data is polled and handed over. In addition to this, you frequently have offloading to hardware for TCP. I would expect considerably better performance for TCP compared to UDP.
Note that sending high speed data over UDP is usually a bad idea, unless you implement your own congestion control. TCP protects your network from congestion collapses. Use UDP when you have small amounts of data or high timeliness requirements.
iperf- in which case, its the perfect test. Your testing should reflect the real world load - otherwise the results can be somewhat meaningless. – sonassi Sep 27 '12 at 0:08iperftests continuously, then your methodology is fine. If your future plans is to run OpenVPN over UDP - then your testing methodology is useless. All you're getting at the moment is a throughput figure foriperf- but that is not the same as what your actual application throughput may be. – sonassi Sep 27 '12 at 10:38