Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)

Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1164 bytes --]

Rich Brown <notifications@github.com> writes:

> Here's an RRUL plot from my 7mbps/768kbps DSL circuit. The download
> has good granularity, while the upload plot seems only to have a
> half-dozen data points. This makes it seem faulty, or somehow
> different/disconnected from the other two plots.
>
> I think I once saw a justification for the appearance of the upload
> plot, but I didn't understand it when I read it, and can't find it
> again to review.

Well, it's not really by design, but it's the best we can do with
current tools, unfortunately. Basically, the problem is the way netperf
determines its data output intervals in demo mode: It sends a certain
number of bytes, and waits for that to complete before outputting
anything. And, well, if the link is really slow, this takes a while, so
we don't get a data point until it's done...

> If this behavior is expected, let's document the reason.

Any suggestions as for where to put this so it's easy to find?



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/185#issuecomment-533171576

[-- Attachment #1.2: Type: text/html, Size: 2678 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

Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2435 bytes --]

Rich Brown <notifications@github.com> writes:

>>  Basically, the problem is the way netperf determines its data output intervals in demo mode:
>
> Ahah! That was the explanation, but I wasn't (yet) smart enough to
> comprehend it. [To further test out my understanding... If netperf
> were to use a smaller "data output interval" when it's transmitting,
> it would create more frequent updates and the granularity would be
> higher...]
>
> But I'm not sure that fully explains it unless netperf uses a (very)
> different data output interval for receiving... The download chart has
> hundreds of points, while the ratio between my download and upload is
> about 10:1 (7mbps vs 768kbps) so I'd expect the upload chart to have
> something like dozens of points...

This is because netperf only checks whether it should output a data
point after it has sent a certain number of bytes. 16k in your case
(it's in the series metdata). At 768kbps, 16k bytes takes ~2.6 seconds
to send, so you'll get at most one data point for every such interval.

Now that I'm looking at this again, it seems that you can actually set
the send size. However, lowering it naturally impacts CPU usage. A quick
test on my laptop indicates that lowering it to 512 bytes raises
netperf's CPU usage from ~2% to ~20% for a single flow at half a
gigabit.

So yeah, we could probably lower it somewhat, but to what? We can't
know ahead of time what connection speed we will be running on.

If you want to try a quick test with a smaller size, this patch (to
Flent) adds the option unconditionally; obviously not the right way to
go about it, but it should allow you to test the impact at least:

diff --git a/flent/runners.py b/flent/runners.py
index a75223d..3d5e373 100644
--- a/flent/runners.py
+++ b/flent/runners.py
@@ -1049,6 +1049,7 @@ class NetperfDemoRunner(ProcessRunner):
                        "{marking} -H {control_host} -p {control_port} " \
                        "-t {test} -l {length:d} {buffer} {format} " \
                        "{control_local_bind} {extra_args} -- " \
+                       "-m 512,512 " \
                        "{socket_timeout} {local_bind} -H {host} -k {output_vars} " \
                        "{cong_control} {extra_test_args}".format(**args)
 


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/185#issuecomment-533247772

[-- Attachment #1.2: Type: text/html, Size: 4130 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

Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 735 bytes --]

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...


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/185#issuecomment-536329614

[-- Attachment #1.2: Type: text/html, Size: 2186 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

Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)

[Sebastian Moeller]

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?

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

Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1313 bytes --]

flent-users <notifications@github.com> writes:\r
\r
> Hi Toke,\r
>\r
>> On Sep 29, 2019, at 20:44, Toke Høiland-Jørgensen <notifications@github.com> wrote:\r
>> \r
>> Rich Brown <notifications@github.com> writes:\r
>> \r
>> > Sorry for the delay in responding... The higher granularity makes much\r
>> > better plots (see below).\r
>> \r
>> Great!\r
>> \r
>> > Using `-m 2048,2048` I don't see a whole lot of load on my Mac 2.5 GHz\r
>> > Intel Core i7 at 7mbps/768kbps. Thanks.\r
>> \r
>> No, don't expect it would. The CPU usage thing will hit you at high\r
>> rates (I was testing on a gigabit link).\r
>> \r
>> I'm not sure we can realistically pick an option that works well for\r
>> both slow and fast links. So we may have to add a switch; and then the\r
>> problem becomes what to use for defaults...\r
>\r
> 	How about make it not a "switch" but a numeric parameter, and\r
> 	default to the current default value by principle of least\r
> 	surprise?\r
\r
Well, by "switch" I just meant "new command line option". The obvious\r
form of that would be, as you say, just the ability to set the netperf\r
xfer size directly...\r
\r
\r
-- \r
You are receiving this because you commented.\r
Reply to this email directly or view it on GitHub:\r
https://github.com/tohojo/flent/issues/185#issuecomment-536331577

[-- Attachment #1.2: Type: text/html, Size: 3018 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

Re: [Flent-users] [tohojo/flent] RRUL Upload plot - why such low granularity? (#185)

[Sebastian Moeller]

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