I find nuttcp very useful in those situations. Be sure to use one of the recent betas, I have been using 7.2.1 for UDP with excellent results (decent loss stats and jitter calc) http://nuttcp.net/nuttcp/beta/nuttcp-7.2.1.c As I understand it, it's still developed, 7.3.2 is now out. M On 7 Dec 2014 16:49, "Saku Ytti" <saku@ytti.fi> wrote:
On (2014-12-07 09:24 +1300), Pete Mundy wrote:
Hey,
I've done loads of 1Gbit testing using the entry-level MacBook Air and a Thunderbolt Gigabit Ethernet adapter though, and I disagree with Saku's statement of 'You cannot use UDPSocket like iperf does, it just does not work, you are lucky if you reliably test 1Gbps'. I find iperf testing at 1Gbit on Mac Air with Thunderbolt Eth extremely reliable (always 950+mbit/sec TCP on a good network, and easy to push right to the 1gbit limit with UDP.
In my experience majority of people using iperf in UDP mode do not monitor for packet loss. And once they start doing, they notice they can't go very fast. For me 1 packet loss due to host issues is absolutely too much,I need flat 0, and in optimal scenario, I'd get microsecond resolution jitter statistics.
Granted I've not tried on OSX, perhaps by default it has deeper buffers for UDP. But on Linux, top of the shelf Cisco UCS server with 10GE interfaces running RHEL, and 1Gbps is simply too much, you'll get packet loss. You can observe the packets arriving, but they'll be registered as UDP errors on 'netstat -s', because your program isn't picking them up fast enough.
Things iperf could do to perform better - setsockopt for deeper buffers - recvmmsg to pick up multiple messages with single context switch - raw sockets to reduce overhead
But ultimately you're still going to be very far from 10Gbps, which is doable, if you'll use something like DPDK.
-- ++ytti