From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8914E3B2B1 for ; Sun, 4 Dec 2016 12:13:26 -0500 (EST) Received: by mail-qk0-x241.google.com with SMTP id n204so36508564qke.2 for ; Sun, 04 Dec 2016 09:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kbK8BnNc6VN/wmV+xwWz0yeOHGTi02ZS/oIogrF7RYw=; b=x00KpwuMzDyYl4CsuzR05HtJDe4rZLwOlAzfdNfeTjqa3b3Jr3ZpDfXRMn5QSBFbKq tRIMa/nQSg5Zij9ScTgXLPLjrOL1UzMoXzcCE0Jkq0CcUV9RE533JEKveq+UQ5hj3fcy c9/DUH8cAj0jyPFbmmCvPpFeFOEUJ4cJlKe/07OWH+dLNyjdY4onqemVyuV7dPlAtxTy 3T/t9OfaQnHDsF38Ufdd+kR+WrEtroJ8qXbXpvVvStDA0uhbQEB9aD8OPZ3V4inrSewA 8SrsfVuKecJk9zCi/RUj+CCKbCVukYUI0vIup2GIgPckcPVey1yQRKCa9oN3/UeP5x83 GzQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kbK8BnNc6VN/wmV+xwWz0yeOHGTi02ZS/oIogrF7RYw=; b=kFmayFoBHftBfZQF9PPKniCEfaDQ0SuqauRDB/8PmDeQWgcqVOojZG5gJqUQ8YrFYV 3WVfXsdqAujF6hgIpNTblMpTQnsU9X2Exp5f4maLrjKLJf+Iv2CGZXpjWdWjnPorbluV dHjq/EAjWOw5nznvCtI+g7S7XMxDpMRP+olUu16JPNB4FFzzqdpQevEnrC3yUuVK+XRl lcLo7KAf4ybQ4+5yyYNiZIPR+LwD660yJArqyjh9/7K4oBCM8qeUcQRfHuZYud+3eZlB dHwX17vvfTn6jAEMa/WE+ma+TskEHnA22cC9LhW/3gvEG/zP1qzJCLDOj57O+zRpxTSW mBjQ== X-Gm-Message-State: AKaTC01N6DL5REGgASRFbMJ8dPpDZRahS4AgV42vcskZTKSkfp6FUrtKPQNT8F1vc5RxzhcaA+dBMciQKxyD+Q== X-Received: by 10.55.162.79 with SMTP id l76mr46360509qke.17.1480871606044; Sun, 04 Dec 2016 09:13:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.152.197 with HTTP; Sun, 4 Dec 2016 09:13:25 -0800 (PST) In-Reply-To: <5052DE08-A6AA-4544-B281-5FEBC9572673@gmail.com> References: <5052DE08-A6AA-4544-B281-5FEBC9572673@gmail.com> From: Dave Taht Date: Sun, 4 Dec 2016 09:13:25 -0800 Message-ID: To: Rich Brown Cc: bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] Reasons to prefer netperf vs iperf? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 17:13:26 -0000 On Sun, Dec 4, 2016 at 5:40 AM, Rich Brown wrote: > As I browse the web, I see several sets of performance measurement using = either netperf or iperf, and never know if either offers an advantage. > > I know Flent uses netperf by default: what are the reason(s) for selectin= g it? Thanks. * Netperf + netperf is the preferred network stress tool of the linux kernel devs. + the maintainer is responsive and capable + the code is very fast with nearly no compromises on speed or accuracy we've successfully used it to 40GigE + the code is also very portable + one explicitly versioned version. When you use netperf, you know you are using netperf. - netperf has a pre-OSI (1993) license which makes for default inclusion in debian impossible and elsewhere sometimes dicy - netperf does not have a way to send timestamps within flows - it is very hard to add new tests to netperf - it's test negotiation protocol is less than fully documented and can break between releases (and I'm being kind here) - it could use better real-time support * iperf + More widely available - "Academic" code, often with papers not citing the specific version used - I have generally not trusted the results published either - but aaron finding that major bug in iperf's udp measurements explains a LOT of that. I think. - Has, like, 3-8 non-interoperable versions. - is available in java, for example there *might* be an iperf version worth adopting but I have no idea which one it would be. I started speccing out a flent specific netperf/iperf replacement *years* ago, (twd), but the enormous amount of money/effort required to do it right caused me to dump the project. Also, at the time (because of the need for reliable high speed measurements AND for measurements on obscure, weak, cpus) my preferred language was going to be C, and that too raised the time/money metric into the stratosphere. I had some hope of leveraging owamp one day, but I have more hope now of leveraging the rapidly maturing infrastructure around go, http2, and quic. there are other tools (ndt for example), but getting past that high speed and weird low end cpu requirement were showstoppers, and remains so. I've been fiddling with esr's new "loccount" tool - both to teach myself go, and deeply understand the (deeply flawed) COCOMO software development model, and according to it, replacing netperf would cost: dave@nemesis:~/git/netperf$ loccount -c . all 50968 (100.00%) in 112 files c 41739 (81.89%) in 48 files shell 5125 (10.06%) in 22 files python 2376 (4.66%) in 5 files m4 895 (1.76%) in 11 files autotools 767 (1.50%) in 9 files awk 66 (0.13%) in 2 files Total Physical Source Lines of Code (SLOC) =3D 50968 Development Effort Estimate, Person-Years (Person-Months) =3D 12.41 (148.89= ) (Basic COCOMO model, Person-Months =3D 2.40 * (KSLOC**1.05)) Schedule Estimate, Years (Months) =3D 1.39 (16.74) (Basic COCOMO model, Months =3D 2.50 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) =3D 8.90 Total Estimated Cost to Develop =3D $1798148 (average salary =3D $60384/year, overhead =3D 2.40). ... loccount is a remarkable improvement in speed over "sloccount" (aside from I/O the code is "embarrassingly parallel" and scales beautifully as a function of the number of cores), and has thus far been quite useful for me finally beginning to grok go. Get it at: git clone https://gitlab.com/esr/loccount And the effort in actually understanding the COCOMO model I hope will one day pay off by trying to come up with a model that more accurately models theory costs, development time, maintenence and refactoring costs. (that said, if anyone out there is aware of the state of the art in this - and has code ), I'd appreciate it. What I'd wanted to do was begin to leverage the oft-published lwn stats on kernel development (and churn) and try to see what that costs. (I'm mostly amusing myself by applying age old techniques to go to speed up loccount, rather than worrying about the model. Everybody needs to just relax and do something like this once in a while) > Rich > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org