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" <s...@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 >
