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: AS60781 77.235.32.0/19 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 IM5zDHbsg1upZQAAOr1fkg (envelope-from ) for ; Mon, 27 Aug 2018 14:20:06 +0200 Received: from web6.sd.eurovps.com (web6.sd.eurovps.com [77.235.54.103]) by mail.toke.dk (Postfix) with ESMTPS id 246244A4137 for ; Mon, 27 Aug 2018 14:20:06 +0200 (CEST) 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=d/2fgT+r; dkim=fail reason="signature verification failed" (1024-bit key) header.d=github.com header.i=@github.com header.b=OqC+P85E 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=+tQT9h9ddnYbHbbLImJ3jYnzHSFlmfYpIFOR1iCGVf0=; b=d/2fgT+rXVHvKwhbnNTnpBPslq qXBSSzivKwm1W1lAbQ+gRaO0kQxPmt6wVHuDmrtkjaXJZXHUdUipumiPGqlj/Uop2G1X9KjlXHTPa oS1PQYNgkBfTQ/r3ll7p8HeoJisMduMj454567mf2DchvZotq7uQHv4LORq7l3FhI57k9fe4z0qp1 hqg5vix14HkBbtcQKn+dnkjRE/cxHWcPgNuli5cMZ7ATJ2k8lXhFbKA+c8QOUoVPmd54FRpnQ/80X y6FEf/Z5FhVoox9KIPJY1Tbi2KAOBQ2UzV+nAvlqLviTgIhgv7TYlk+GynuDu3ywm8msPQ6b+3If8 xE+G5swg==; Received: from [::1] (port=49554 helo=web6.sd.eurovps.com) by web6.sd.eurovps.com with esmtp (Exim 4.91) (envelope-from ) id 1fuGV3-008Bf1-7B; Mon, 27 Aug 2018 15:20:05 +0300 Received: from out-5.smtp.github.com ([192.30.252.196]:56703) by web6.sd.eurovps.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fuGUx-008BQQ-Mf for flent-users@flent.org; Mon, 27 Aug 2018 15:20:02 +0300 Date: Mon, 27 Aug 2018 05:19:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1535372358; bh=yYNSSBCxqWGwdNwoKl5IsXtypn98AH27lhQ36n2h/yQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OqC+P85E/x7sfXlqCv7q2XSQQVINn+znwLBdLIl7F0QWVTfoYMGvfcCpRHgAkD2bh Dnr/57aRLF8M7CNzLQJFvCBca66273T/JbSIvBG5zc/+ka4bAJ7xgzXXndGLKBIk7z o9dRM5CcSPYFrobC8/9wLZgpnSWe/hdZL56veVGU= 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 Subject: Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148) X-BeenThere: flent-users@flent.org X-Mailman-Version: 2.1.26 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="===============7581417430311206441==" 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 --===============7581417430311206441== Content-Type: multipart/alternative; boundary="--==_mimepart_5b83ec46e8530_3f3a3f8c37ad45b410638ef"; charset=UTF-8 Content-Transfer-Encoding: 7bit ----==_mimepart_5b83ec46e8530_3f3a3f8c37ad45b410638ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pete Heist writes: >> On Aug 27, 2018, at 1:40 PM, flent-users wr= ote: >> = >> Hi Pete, >> = >> > On Aug 25, 2018, at 19:53, Pete Heist wro= te: >> > = >> > 50ms wouldn't be too disruptive in most cases. At 1 Mbit, the 5% of = bandwidth threshold is crossed. >> = >> Would it be possible to simply also show this bandwidth use in the >> bandwidth plots (say as a single data series accumulated over all >> irtt probes), then the user could select the interval and still be >> able to easily assess the effects on other bandwidth flows? I believe >> that would also be great for the netperf UDP/ICMP streams, but >> probably harder to implement > > > We could, but I would think what might happen is that in most cases > you=E2=80=99ll have a line that appears close to 0 Mbit, relative to ot= her > flows, and we probably wouldn=E2=80=99t want to change the scaling for = the > scaled bandwidth plots to accommodate that... I think the important part of this is that it would be reflected in the total bandwidth score. I've been meaning to implement this for a while for netperf UDP_RR, because otherwise you can get spurious bandwidth drops as latency decreases just because the latency measurement flows take up more bandwidth. But, well, irtt sort of made that less urgent ;) But I could revisit; I do believe I already capture the data from irtt (I think?). -Toke -- = You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/148#issuecomment-416208064= ----==_mimepart_5b83ec46e8530_3f3a3f8c37ad45b410638ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pete Heist <notifications@github.com> writes:

>> On Aug 27, 2018, at 1:40 PM, flent-users <notifications@githu= b.com> wrote:
>>
>> Hi Pete,
>>
>> > On Aug 25, 2018, at 19:53, Pete Heist <notifications@git= hub.com> wrote:
>> >
>> > 50ms wouldn't be too disruptive in most cases. At 1 Mbi= t, the 5% of bandwidth threshold is crossed.
>>
>> Would it be possible to simply also show this bandwidth use in t= he
>> bandwidth plots (say as a single data series accumulated over al= l
>> irtt probes), then the user could select the interval and still = be
>> able to easily assess the effects on other bandwidth flows? I be= lieve
>> that would also be great for the netperf UDP/ICMP streams, but >> probably harder to implement
>
>
> We could, but I would think what might happen is that in most cases<= br> > you=E2=80=99ll have a line that appears close to 0 Mbit, relative to= other
> flows, and we probably wouldn=E2=80=99t want to change the scaling f= or the
> scaled bandwidth plots to accommodate that...

I think the important part of this is that it would be reflected in the total bandwidth score. I've been meaning to implement this for a whil= e
for netperf UDP_RR, because otherwise you can get spurious bandwidth
drops as latency decreases just because the latency measurement flows
= take up more bandwidth. But, well, irtt sort of made that less urgent ;)<= br>
But I could revisit; I do believe I already capture the data from irtt (I think?).

-Toke

&m= dash;
You are receiving this because you commented.
Reply to th= is email directly, view it on GitHub, or mute the thread.3D""

= ----==_mimepart_5b83ec46e8530_3f3a3f8c37ad45b410638ef-- --===============7581417430311206441== 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 --===============7581417430311206441==--