From: "Toke Høiland-Jørgensen" <notifications@github.com>
To: tohojo/flent <flent@noreply.github.com>
Cc: Comment <comment@noreply.github.com>,
flent-users <flent-users@flent.org>
Subject: Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)
Date: Mon, 27 Aug 2018 05:19:18 -0700 [thread overview]
Message-ID: <tohojo/flent/issues/148/416208064@github.com> (raw)
In-Reply-To: <tohojo/flent/issues/148@github.com>
[-- Attachment #1.1: Type: text/plain, Size: 1634 bytes --]
Pete Heist <notifications@github.com> writes:
>> On Aug 27, 2018, at 1:40 PM, flent-users <notifications@github.com> wrote:
>>
>> Hi Pete,
>>
>> > On Aug 25, 2018, at 19:53, Pete Heist <notifications@github.com> wrote:
>> >
>> > 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’ll have a line that appears close to 0 Mbit, relative to other
> flows, and we probably wouldn’t 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
[-- Attachment #1.2: Type: text/html, Size: 6640 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org
next prev parent reply other threads:[~2018-08-27 12:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tohojo/flent/issues/148@github.com>
2018-08-19 0:26 ` Dave Täht
2018-08-27 12:19 ` Toke Høiland-Jørgensen [this message]
2018-09-03 17:37 ` Toke Høiland-Jørgensen
2018-09-03 20:23 ` Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.flent.org/postorius/lists/flent-users.flent.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tohojo/flent/issues/148/416208064@github.com \
--to=notifications@github.com \
--cc=comment@noreply.github.com \
--cc=flent-users@flent.org \
--cc=flent@noreply.github.com \
--cc=reply+01ead4bf11caebfe718bb3272426be366e0ee4a084dbf16c92cf00000001179bae4692a169ce14f88d92@reply.github.com \
--subject='Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'\''d flows (#148)' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox