From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.toke.dk X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.1 Received: from mail.toke.dk by mail.toke.dk with LMTP id 0KikN6iBDVrmUgAAOr1fkg for ; Thu, 16 Nov 2017 13:16:40 +0100 Received: from web6.sd.eurovps.com (web6.sd.eurovps.com [77.235.54.103]) by mail.toke.dk (Postfix) with ESMTPS id 77AD622E5B2 for ; Thu, 16 Nov 2017 13:16:39 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=fail reason="key not found in DNS" (0-bit key) header.d=flent.org header.i=@flent.org header.b=KnB8nno1; dkim=fail reason="signature verification failed" (1024-bit key) header.d=github.com header.i=@github.com header.b=tjHRbdiM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=flent.org; s=default; h=Sender:Content-Type:Cc:Reply-To:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:Subject:Mime-Version: References:In-Reply-To:Message-ID:To:From:Date:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VcTbx19BGpQxo3efBCL6EXVnFav12SwF+0UCMSBMVro=; b=KnB8nno1GsJTbFZmhSjnmB9RV/ imAH4+SN0kkgKWTImdXCKvmJccjOmPIvLWoQe/E5voMx+V+ng0gWzUb6NLcABp6KBMx8HWomjW7Ek qwIeiskTqt3UBWtMhs7hxYi8UZmBseFigTeTzGuShgWeRatsUa5aJNzBoa9RLrNaxzH/4589fqB98 eHLC8tQvRORX/52qqqY5bPHmL+achFfyq7QQgEZxeivnIeXAiax0kWPOlGstsi9Vc1WWUaeRqklct k7pGdUYnP9+0ZckAF4uSAifknXvk8HRX0oXcoBLx5I+y1nt6KZN1Ogp2qIAZ7QK4Nj6ZyaHiLVni8 F3OWm7HA==; Received: from [::1] (port=57794 helo=web6.sd.eurovps.com) by web6.sd.eurovps.com with esmtp (Exim 4.89) (envelope-from ) id 1eFJ5x-004NER-Oo; Thu, 16 Nov 2017 14:16:37 +0200 Received: from o1.sgmail.github.com ([192.254.114.176]:60705) by web6.sd.eurovps.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eFJ5n-004N4z-QG for flent-users@flent.org; Thu, 16 Nov 2017 14:16:36 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=76jojjSU/5KaDW4MXY295vOh/ws=; b=tjHRbdiMvxzGoPqr 81ZY19eOaBx/G3zU4EJvplaae2hvuOJvcDft8zrahMcveymmzY3llrMd0MDZGAbI qgEJ0GEw4U/NyyvvWVWYtIRDXqSpMJMO4xTOnyY9pqV4s5unPztoy6X0DirkxJB9 o5BPPQxY6VWUENAINV22lwk4/ik= Received: by filter0504p1iad2.sendgrid.net with SMTP id filter0504p1iad2-28372-5A0D8171-22 2017-11-16 12:15:45.908650275 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0007p1iad1.sendgrid.net (SG) with ESMTP id eMRcCG0eRgqUcoO-VR6gqg for ; Thu, 16 Nov 2017 12:15:45.750 +0000 (UTC) Date: Thu, 16 Nov 2017 12:15:45 +0000 (UTC) From: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= To: tohojo/flent Message-ID: In-Reply-To: References: Mime-Version: 1.0 Precedence: list X-GitHub-Sender: tohojo X-GitHub-Recipient: flent-users X-GitHub-Reason: comment X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: flent-users@flent.org tracking: X-SG-EID: IRsowsd9yCOJafMG0EWGsh26xBq50lgDrxWUlCCqUntTB9v3KfW/b0YXwTpoNoor+i9pVzKjux65uW fy5Fko7y0Xo8lX3z6m7BZen9LMU+7ytp/s0MNAzzxUDDCPW8i7SLGbO7uoK1noBcW+xQrKLykwZvzr ub9RhWmTrr1VzPX1I2QCd0zD/wZyqTi7vay1XEuwMPZvnp+K1nIH5zND/HuipmCHC6DuBNZtfAZYX3 fZnonmbQHBiznMnRLH+2Ts Subject: Re: [Flent-users] [tohojo/flent] packet loss stats (#106) X-BeenThere: flent-users@flent.org X-Mailman-Version: 2.1.23 List-Id: Flent discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: tohojo/flent Cc: Comment , flent-users Content-Type: multipart/mixed; boundary="===============5718537771274175649==" Errors-To: flent-users-bounces@flent.org Sender: "Flent-users" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web6.sd.eurovps.com X-AntiAbuse: Original Domain - toke.dk X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - flent.org X-Get-Message-Sender-Via: web6.sd.eurovps.com: acl_c_authenticated_local_user: mailman/mailman X-Authenticated-Sender: web6.sd.eurovps.com: mailman@flent.org --===============5718537771274175649== Content-Type: multipart/alternative; boundary="--==_mimepart_5a0d817199b19_37f23fbca095cf30107799b"; charset=UTF-8 Content-Transfer-Encoding: 7bit ----==_mimepart_5a0d817199b19_37f23fbca095cf30107799b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Pete Heist writes: > Cool, the rrul_be_irtt test is working for me. I see what you mean, > ideally it would just be the same test but you substitute the tool you > want to use for a particular measurement. > > Maybe this is what you're saying, but could it be that you specify > what tool you want to use for each particular measurement? In other > words, the tool for 'TCP throughput' is netperf as of now, and later > could possibly be iperf. For 'UDP RTT' it can be netperf or irtt. For > 'ICMP RTT' it can be ping or fping, etc. Yeah, something like that. For ping we already do this (default to fping and fall back to regular ping), but those are closer in functionality. But the idea is the same; the test should not specify "use netperf" but rather "this is a UDP RR test". Then we pick irtt if it's available and use netperf as a fallback. Optionally with a command line switch to force fallback (probably a good idea at least until we get wider deployment of irtt). > I'm waving my arms here because there can be more than one measurement > from a single tool. So maybe it should really be 'UDP RT' because in > the case of irtt it's doing a UDP round-trip and measuring several > things from it at once: RTT, OWD, IPDV, etc. Since there isn't a > one-to-one correspondence between the tool and measurement it returns, > it's not clear to me yet how it should be specified, still thinking > about it. > > I guess at some point there will be additional plots for OWD and IPDV. > Is it a new situation for you that the plots available depend not only > on the test but the tool used or even its settings? Meh, irtt's functionality is basically a superset of netperf's UDP_RR. So automatically picking irtt if available and a fallback is the right thing to do, I think. I'd just add the plots everywhere, and if OWD data is not available, those plots would just be empty. Same thing we do for TCP window stats currently. Longer term, maybe hiding the plots entirely when there is no data is better, but for now empty plots are fine. > Personally I don't think it's necessary to check for server-side > support. If someone is specifying they want to use a particular tool, > I think they're declaring that it's available, as it is today with > netperf / netserver. Yes, but if we do automatic detection with a preference we could get into the situation where irtt exists on the client but the test is being run against a server that doesn't have it. This is especially likely to happen before the *.netperf.bufferbloat.net servers have irtt deployed. Could you be persuaded to add a 'check_server' action to irtt? Something that just does the handshake and doesn't run any more tests other than that. Then we could have Flent call that to verify that irtt is usable... -Toke -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/106#issuecomment-344905911 ----==_mimepart_5a0d817199b19_37f23fbca095cf30107799b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pete Heist <notifications@github.com> writes:

> Cool, the rrul_be_irtt test is working for me. I see what you mean,
> ideally it would just be the same test but you substitute the tool you=
> want to use for a particular measurement.
>
> Maybe this is what you're saying, but could it be that you specify=
> what tool you want to use for each particular measurement? In other
> words, the tool for 'TCP throughput' is netperf as of now, and= later
> could possibly be iperf. For 'UDP RTT' it can be netperf or ir= tt. For
> 'ICMP RTT' it can be ping or fping, etc.

Yeah, something like that. For ping we already do this (default to fping
and fall back to regular ping), but those are closer in functionality.
But the idea is the same; the test should not specify "use netperf&quo= t; but
rather "this is a UDP RR test". Then we pick irtt if it's ava= ilable and
use netperf as a fallback. Optionally with a command line switch to
force fallback (probably a good idea at least until we get wider
deployment of irtt).

> I'm waving my arms here because there can be more than one measure= ment
> from a single tool. So maybe it should really be 'UDP RT' beca= use in
> the case of irtt it's doing a UDP round-trip and measuring several=
> things from it at once: RTT, OWD, IPDV, etc. Since there isn't a > one-to-one correspondence between the tool and measurement it returns,=
> it's not clear to me yet how it should be specified, still thinkin= g
> about it.
>
> I guess at some point there will be additional plots for OWD and IPDV.=
> Is it a new situation for you that the plots available depend not only=
> on the test but the tool used or even its settings?

Meh, irtt's functionality is basically a superset of netperf's UDP_= RR.
So automatically picking irtt if available and a fallback is the right
thing to do, I think. I'd just add the plots everywhere, and if OWD dat= a
is not available, those plots would just be empty. Same thing we do for
TCP window stats currently. Longer term, maybe hiding the plots entirely
when there is no data is better, but for now empty plots are fine.

> Personally I don't think it's necessary to check for server-si= de
> support. If someone is specifying they want to use a particular tool,<= br> > I think they're declaring that it's available, as it is today = with
> netperf / netserver.

Yes, but if we do automatic detection with a preference we could get
into the situation where irtt exists on the client but the test is being
run against a server that doesn't have it. This is especially likely to=
happen before the *.netperf.bufferbloat.net servers have irtt deployed.

Could you be persuaded to add a 'check_server' action to irtt? Some= thing
that just does the handshake and doesn't run any more tests other than<= br> that. Then we could have Flent call that to verify that irtt is
usable...

-Toke

&mda= sh;
You are receiving this because you commented.
Reply to this e= mail directly, view it on GitHub, or mute the thread.3D""

= ----==_mimepart_5a0d817199b19_37f23fbca095cf30107799b-- --===============5718537771274175649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Flent-users mailing list Flent-users@flent.org http://flent.org/mailman/listinfo/flent-users_flent.org --===============5718537771274175649==--