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 ` 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 \ --subject='Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)' \ /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