[176628] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: 10Gb iPerf kit?

daemon@ATHENA.MIT.EDU (Matthew Walster)
Sun Dec 7 06:57:24 2014

X-Original-To: nanog@nanog.org
In-Reply-To: <20141207084804.GA12884@pob.ytti.fi>
Date: Sun, 7 Dec 2014 19:57:15 +0800
From: Matthew Walster <matthew@walster.org>
To: Saku Ytti <saku@ytti.fi>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

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
>

home help back first fref pref prev next nref lref last post