From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4536D3B25E for ; Tue, 20 Sep 2016 18:03:55 -0400 (EDT) Received: from dair-2506.local (c-73-15-8-67.hsd1.ca.comcast.net [73.15.8.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 21F0521317 for ; Tue, 20 Sep 2016 22:03:53 +0000 (UTC) To: bloat@lists.bufferbloat.net References: From: =?UTF-8?Q?Dave_T=c3=a4ht?= Message-ID: Date: Tue, 20 Sep 2016 15:03:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] iperf3 and packet bursts 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: Tue, 20 Sep 2016 22:03:55 -0000 Groovy. I note that I am really fond of the linux "fdtimer" notion for tickers, we use that throughout the high speed stats gathering code in flent. I'd really like a voip or ping tool that used those, and I've always worried about iperf's internal notion of a sampling interval. On 9/20/16 3:00 PM, Aaron Wood wrote: > We were using iperf3 at work to test a network path (we wanted the > fixed-rate throttling that it can do). And while TCP would fill the > 50Mbps link from the ISP, UDP couldn't. UDP couldn't get over 8Mbps of > goodput, no matter what rate we specified on the command line. > > We found a 100ms timer that's used to PWM the packet transmission to > perform the throttling. Fine for TCP, fine where the end-to-end > physical links are the same rate. But throw a 10:1 rate change through > a switch into that, and suddenly you find out that the switch isn't that > bloated. > > I modified iperf3 to use a 1ms timer, and was able to get things much > smoother. I doubt it's as smooth as iperf3 gets on Linux when fq pacing > is used, but it's a big improvement vs. the nice small buffers in switches. > > I put together a writeup with graphs on my blog: > http://burntchrome.blogspot.com/2016/09/iperf3-and-microbursts.html > > I have a forked version of iperf3 on github: > https://github.com/woody77/iperf > > This uses the 1ms timer, and has a few other fixes, such as it resets > the throttling calculations at the start of each stats interval. That > change stops iperf3 from transmitting at maximum rate after congestion > has stopped it from achieving the target rate. There will be another > writeup on that, but I need to get some good sample data together for > graphing. > > -Aaron Wood > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >