From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.toke.dk X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.2 Received: from mail.toke.dk by mail.toke.dk with LMTP id dFhlCIjFg11iHQAAOr1fkg (envelope-from ) for ; Thu, 19 Sep 2019 20:14:32 +0200 Authentication-Results: mail.toke.dk; none (SPF check N/A for local connections - client-ip=77.235.54.103; helo=web6.sd.eurovps.com; envelope-from=flent-users-bounces@flent.org; receiver=) Authentication-Results: mail.toke.dk; dkim=fail reason="signature verification failed" (1024-bit key) header.d=github.com header.i=@github.com header.b=pVMmQmUE Received: from web6.sd.eurovps.com (web6.sd.eurovps.com [77.235.54.103]) by mail.toke.dk (Postfix) with ESMTPS id F186566C16A for ; Thu, 19 Sep 2019 20:14:29 +0200 (CEST) Received: from [::1] (port=52842 helo=web6.sd.eurovps.com) by web6.sd.eurovps.com with esmtp (Exim 4.92) (envelope-from ) id 1iB0wl-00DCtp-V0; Thu, 19 Sep 2019 21:14:27 +0300 Received: from out-24.smtp.github.com ([192.30.252.207]:35967) by web6.sd.eurovps.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iB0we-00DCoL-Io for flent-users@flent.org; Thu, 19 Sep 2019 21:14:26 +0300 Date: Thu, 19 Sep 2019 11:13:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1568916819; bh=ikejW3jXtLWksAvEaSPtumj7J+cjzYA2TX80eIt0oyg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pVMmQmUEbk+4cQkGRCwBpdfr/eM49hWR2DAAnQu95DMbT/xg1dLz/yAd3ZTMtbXng y8ejb5cPXIm8l6ZFdDFEAusQIDwiR5y4fmr3M1LW6esLKcZy1mklzZJMSL7/p2FFbW Xivb9v4bPI2OqglE/8ScRAMWdUNVJKoUrCDA1Ads= 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] RRUL Upload plot - why such low granularity? (#185) X-BeenThere: flent-users@flent.org X-Mailman-Version: 2.1.27 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="===============8246092107389284306==" 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 --===============8246092107389284306== Content-Type: multipart/alternative; boundary="--==_mimepart_5d83c5539f8d3_3a0c3fe1ae6cd96c1854d"; charset=UTF-8 Content-Transfer-Encoding: 7bit ----==_mimepart_5d83c5539f8d3_3a0c3fe1ae6cd96c1854d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Rich Brown 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 ----==_mimepart_5d83c5539f8d3_3a0c3fe1ae6cd96c1854d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, view it on GitHub, or mute the thread.

----==_mimepart_5d83c5539f8d3_3a0c3fe1ae6cd96c1854d-- --===============8246092107389284306== 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 --===============8246092107389284306==--