Re: [bmwg] Mean vs Median

Marius Georgescu <liviumarius-g@is.naist.jp> Tue, 10 November 2015 01:19 UTC

Return-Path: <liviumarius-g@is.naist.jp>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13401B2D44 for <bmwg@ietfa.amsl.com>; Mon, 9 Nov 2015 17:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level:
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eM8PB0umcxs for <bmwg@ietfa.amsl.com>; Mon, 9 Nov 2015 17:19:33 -0800 (PST)
Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [IPv6:2001:200:16a:50::91]) by ietfa.amsl.com (Postfix) with ESMTP id F19DD1B2D41 for <bmwg@ietf.org>; Mon, 9 Nov 2015 17:19:32 -0800 (PST)
Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id 5AB2963B for <bmwg@ietf.org>; Tue, 10 Nov 2015 10:19:31 +0900 (JST)
Received: from naist-wavenet125-152.naist.jp (naist-wavenet125-152.naist.jp [163.221.125.152]) by mailpost22.naist.jp (Postfix) with ESMTPSA id 43B9D63A for <bmwg@ietf.org>; Tue, 10 Nov 2015 10:19:31 +0900 (JST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Marius Georgescu <liviumarius-g@is.naist.jp>
In-Reply-To: <5640DA91.30502@net.in.tum.de>
Date: Tue, 10 Nov 2015 10:18:58 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C1BEDBD-2338-4E1B-8C98-E9479FE01423@is.naist.jp>
References: <6b20c5aba195.56384250@naist.jp> <6c1081bddbe0.563844ac@naist.jp> <6c1084a7be89.563844e9@naist.jp> <6a608b65b1c2.56384525@naist.jp> <6a60d6ebaa6a.56384561@naist.jp> <6a80d3baddd6.5638459e@naist.jp> <6aa08a52c1ca.563845da@naist.jp> <6aa09799f4a7.563846ca@naist.jp> <6b60a07c9bbf.56384707@naist.jp> <6c109c80bfc2.56384743@naist.jp> <6a60e1ff9170.56384780@naist.jp> <6a60f4388bab.563847bc@naist.jp> <6bd0f10697e2.563847f8@naist.jp> <6a409179ad4a.56384835@naist.jp> <6a80cfd8c72d.56384871@naist.jp> <6c30b15ad280.563848ae@naist.jp> <6c30f0e98215.563848ea@naist.jp> <6c10c39aeff9.56384926@naist.jp> <6ab08659b996.56384963@naist.jp> <6ab0ea4dfdd6.563849a0@naist.jp> <6ab0be62e098.563849dc@naist.jp> <6aa0abb5b14b.56384a19@naist.jp> <6aa0e679a9c8.56384a55@naist.jp> <6b60e1babb96.56384a93@naist.jp> <6b60fdd88897.56384acf@naist.jp> <6a509431f711.56384c39@naist.jp> <6a50aab7bf13.5638cb72@naist.jp> <CAPrseCo-E82O+tSvRC=4x-yXYTMEHUW6UjeQK6HBRZwXey=sKg@mail.gmail.com> <5640DA91.30502@net.in.tum .de>
To: bmwg@ietf.org
X-Mailer: Apple Mail (2.2104)
X-TM-AS-MML: No
X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-21932.003
X-TM-AS-Result: No--13.656-5.0-31-10
X-imss-scan-details: No--13.656-5.0-31-10
X-TMASE-MatchedRID: aFaKFnJZSSKPvrMjLFD6eB5+URxv1WlBGcfGM6EiL4YM74Nf6tTB9khP Q0eK2cxb+BmvCg26LIyir5lW0HlHPiaLMKkKU7qc5cXAEGYV3gxqYquCrLrVwt9RlPzeVuQQsyP cYASVAYS0gREACagb1JOSQtWDiAvi2HzzjwqZ3wKPmEs8Jfdl08TSu/aIHyCpU7pNZ8dlJ+GKWb xlrWNyCV08/FpVEVqi8ZWzO5eT4he29qwJFyhl0xHRbGr1ECgHIcCiCHZJTld/D8iN+xdNb2KKT NKDv61zw9fZUI4Jn+vDdw4qHopkTF2V546KEHXIw69AIwXJn0a2raKhDLB9XX5h6y4KCSJcGxUU 8gXhKoFJz8hK9Qu/5ib5Ut7KJ2ZT4fEVvamOvhsAKzYLecaUGJPWrYhEvfadbJknz+3f3aWfgA0 BJtIcvRwEXyNHnTqJuTg5bcaJSXlhaj10i6TXQEK9qlwiTElfdZPoD9V2prSbKItl61J/ybLn+0 Vm71LcljNfzQcnhdey9Q92ZKlY2s4XLBsYBeuCKrauXd3MZDVxgujXfgLTHdWTSyK02EIkGiAjH fIOKOsKGD9H4dGvnxvIsr7OTYBB
Archived-At: <http://mailarchive.ietf.org/arch/msg/bmwg/y-bbss5hKTdRvwBl-3C2Cq8Qd4A>
Subject: Re: [bmwg] Mean vs Median
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2015 01:19:34 -0000

Hi Paul,

Please see my answers inline.


> On Nov 10, 2015, at 02:40, Paul Emmerich <emmericp@net.in.tum.de> wrote:
> 
> Hi,
> 
> On 03.11.15 09:45, Stenio Fernandes wrote:
>> a word of caution here... a number of phenomena in computer networks
>> follows a heavy-tailed probability distribution function, which means
>> that there is a non-negligible probability that a random variable will
>> take huge values. these values might be erroneously considered as outliers.
> 
> this is a really important point. I have benchmarked software where the 99th percentile of the latency is twice the average/median and the 99.9th percentile ten times the average/median.

Can you give us more context (test setup; physical/virtualized tester/DUT; one tester/sender_receiver tester ... ) on these measurements?

> This is an important performance characteristic for latency-sensitive applications that isn't captured by taking just 20 measurements. So I'd really like to see a standard that calls for thousands of latency measurements to capture this properly.
> 

I think we should keep practicality in mind here. If we follow RFC2544.latency measurement, the frame stream has to be 2 min long. 2000 min ~ 33h  of testing for just one test sounds unreasonable to me. I would agree to have a lower bound for the sample size as RFC2544 actually recommends (n > 20). 

> You can also get interesting insights into a black-box device by looking at histograms/probability density functions. For example, you can figure out if the device processes packets in batches, estimate the batch size, figure out at which rates interrupt moderation algorithms change etc. (This is, of course, not really a performance metric, just an interesting insight.)
> 

I agree this is an interesting insight. It can also be the base for a decision between summarizing functions. However, in the light of consistency and simplicity of the methodology, I think we would need to recommend one function. We could do that depending on the metric/DUT characteristics, previous testing behavior …

> 
> Paul
> 
> -- 
> Paul Emmerich
> Technical University of Munich (TUM)
> Department of Informatics
> Chair for Network Architectures and Services
> 
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg