From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by huchra.bufferbloat.net (Postfix) with ESMTP id ACA0A208AB4 for ; Tue, 27 Nov 2012 08:41:27 -0800 (PST) Received: from [IPv6:2001:470:96b9:1:14cb:af2e:2e24:2838] (ibis.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:1:14cb:af2e:2e24:2838]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 7FFFE4C2A13 for ; Tue, 27 Nov 2012 17:41:24 +0100 (CET) Message-ID: <50B4ED31.9000103@net.t-labs.tu-berlin.de> Date: Tue, 27 Nov 2012 17:41:21 +0100 From: Oliver Hohlfeld User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <20121123221842.GD2829@linux.vnet.ibm.com> <87a9u7amon.fsf@toke.dk> <87txscm2lm.fsf@toke.dk> <87obiklzm4.fsf@toke.dk> <1353973198.619924429@apps.rackspace.com> <87ip8rncg5.fsf@toke.dk> In-Reply-To: <87ip8rncg5.fsf@toke.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 16:41:28 -0000 >> iperf is a "hot rod" test. The UDP versions ignores congestion signals >> entirely, and thus is completely irrelevant to bufferbloat. > > Well I wasn't going to run it at full speed (whatever that might mean), > but limit it to a relatively low speed, to get the jitter measurements > for UDP in the hope they'd be a decent indication for how a voip call > might fare on the same connection. If you have ideas for a better tool, > I'm all ears. :) It is not only about the tool, it is about the traffic scenario that you have in mind. There is no such thing as "the VoIP quality". UDP jitter: in which traffic scenario? A medium loaded backbone link? An access link in overload? And also keep in mind that this only holds for the absence of TCP traffic, i.e., there is only UDP traffic competing with other UDP traffic. Keep in mind that the relationship of jitter to VoIP quality is complex, as it depends on the application level buffering. There are also more impact factors other than jitter. The jitter measurements you have in mind will give you an idea on the jitter specific to the chosen traffic scenario, nothing more --- and in particular not the VoIP quality (although low vs. high jitter could /indicate/ certain /possible/ quality degradations). --Oliver