From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4BFBF3BA8E for ; Wed, 29 Nov 2017 11:21:25 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1511972483; bh=CR0VgXAddAxGAlQD2VbklG0lqjEHZFhIoxL8jN6LjJ4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=D+lJzGqPKzJK6arxZ3ZmMf8kEbF3ELoBrFUdE/vfxNI0a3WEaERlXUub60VBcfbso WU/o2KUEmdaYjPlKvsaJj5MJdPThA4WJIlA2iLTYras5h7I/JxJkPyMqgq2pKx9IjR HDl6UQ3hm5/lLACAQ3YqyzpzUEvAT240gLP/rgQCsuxLWb+Dvn6VklGBEWkKjeJc+z NKmPQlCdnEaT69lKqLD8u4KcppU74dOZptJtUZ2ATXzKtwsr2Y4cXNM09gwJ1jzTrt aaBRV3GinXsljW8heWvZAIl2kjGQSZFgQGlAPffSVhJ/CalpNsdyUrAGF2PZAGxUMb 9RNKbM+2IjHZQ== To: Pete Heist Cc: Georgios Amanakis , Cake List In-Reply-To: <15453B62-04DD-4F00-B7E9-BC7469A2FAFE@gmail.com> References: <745FEC66-95A7-40E1-A8FA-57714D3AB6AC@gmail.com> <87zi76xlw5.fsf@nemesis.taht.net> <6F2894AD-87EA-4EFC-918E-625E49EDA977@gmail.com> <87o9nmxcbg.fsf@nemesis.taht.net> <87bmjmxbgw.fsf@nemesis.taht.net> <3FAFACA8-C918-4325-BF80-B7EBB6B9B4A7@gmail.com> <87k1y96swh.fsf@toke.dk> <20760855-77A6-456D-BFDB-2A5D17C4528A@gmail.com> <878tep6qdp.fsf@toke.dk> <15453B62-04DD-4F00-B7E9-BC7469A2FAFE@gmail.com> Date: Wed, 29 Nov 2017 17:21:21 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87374x6oou.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] cake flenter results round 2 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 16:21:25 -0000 Pete Heist writes: >> On Nov 29, 2017, at 4:44 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >>> (That was also informative for me about how netperf decides when to >>> emit a data point=E2=80=A6) >>=20 >> In that case I can add that the stated reason for this way of doing >> things is performance (i.e., emitting data points should not interfere >> with transfer performance). This is mostly an issue on systems where >> getting time is expensive; which is not the case on modern Linux >> systems. But I'm not entirely sure that the optimisation only has >> historical reasons; it may be that some systems supported by Netperf >> still has this issue... > > Nice, I do respect the level of thought put into netperf=E2=80=A6 Yup, netperf is the result of decades of optimisation, and widely trusted, especially in the kernel community. Which is the main reason why I chose it when first designing Flent (which was originally called netperf-wrapper for this reason :)). The flip side of this is that netperf does have its oddities and nooks and crannies, and can feel arcane at times. And the code is somewhat intimidating. So a clean slate tool like irtt definitely has its place as well ;) -Toke