From: Sebastian Moeller <moeller0@gmx.de>
To: tohojo/flent
<reply+AHVNJP5TBZ2RLAX6JBA647F3TYZ2NEVBNHHB3DQ34A@reply.github.com>
Cc: tohojo/flent <flent@noreply.github.com>,
Comment <comment@noreply.github.com>,
flent-users <flent-users@flent.org>
Subject: Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)
Date: Sun, 29 Sep 2019 21:34:46 +0200 [thread overview]
Message-ID: <6D925525-6E60-4CCE-AD78-C472800F2331@gmx.de> (raw)
In-Reply-To: <tohojo/flent/issues/185/536331577@github.com>
Hi Toke,
> On Sep 29, 2019, at 21:08, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>
> flent-users <notifications@github.com> writes:
>
> > Hi Toke,
> >
> >> On Sep 29, 2019, at 20:44, Toke Høiland-Jørgensen <notifications@github.com> wrote:
> >>
> >> Rich Brown <notifications@github.com> writes:
> >>
> >> > Sorry for the delay in responding... The higher granularity makes much
> >> > better plots (see below).
> >>
> >> Great!
> >>
> >> > Using `-m 2048,2048` I don't see a whole lot of load on my Mac 2.5 GHz
> >> > Intel Core i7 at 7mbps/768kbps. Thanks.
> >>
> >> No, don't expect it would. The CPU usage thing will hit you at high
> >> rates (I was testing on a gigabit link).
> >>
> >> I'm not sure we can realistically pick an option that works well for
> >> both slow and fast links. So we may have to add a switch; and then the
> >> problem becomes what to use for defaults...
> >
> > How about make it not a "switch" but a numeric parameter, and
> > default to the current default value by principle of least
> > surprise?
>
> Well, by "switch" I just meant "new command line option".
Oops, sorry, I read this as a switch to toggle between say the default (which seems system dependent not petperf dependent, no?) and a value for low bandwidth links, say 1460...
> The obvious
> form of that would be, as you say, just the ability to set the netperf
> xfer size directly...
I guess that would be the best compromise, if the user knows about a links asymmetry the send and receive buffers can be sized accordingly like 16K, 1600 for DOCSIS down-/upload...
I also wonder whether flent should not try to also record and parse /proc/stat to detect CPU overload (so the user could be warned/informed to increase the xfer size if there is danger of being CPU bound)?
Best Regards
Sebastian
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
> _______________________________________________
> Flent-users mailing list
> Flent-users@flent.org
> http://flent.org/mailman/listinfo/flent-users_flent.org
_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org
prev parent reply other threads:[~2019-09-29 19:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tohojo/flent/issues/185@github.com>
2019-09-19 14:59 ` [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185) Toke Høiland-Jørgensen
2019-09-19 18:13 ` Toke Høiland-Jørgensen
2019-09-29 18:44 ` Toke Høiland-Jørgensen
2019-09-29 19:05 ` Sebastian Moeller
2019-09-29 19:08 ` Toke Høiland-Jørgensen
2019-09-29 19:34 ` Sebastian Moeller [this message]
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=6D925525-6E60-4CCE-AD78-C472800F2331@gmx.de \
--to=moeller0@gmx.de \
--cc=comment@noreply.github.com \
--cc=flent-users@flent.org \
--cc=flent@noreply.github.com \
--cc=reply+AHVNJP5TBZ2RLAX6JBA647F3TYZ2NEVBNHHB3DQ34A@reply.github.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox