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 66D7OgqYg10LUwAAOr1fkg (envelope-from ) for ; Thu, 19 Sep 2019 17:00:26 +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=) Received: from web6.sd.eurovps.com (web6.sd.eurovps.com [77.235.54.103]) by mail.toke.dk (Postfix) with ESMTPS id E045C66BF88 for ; Thu, 19 Sep 2019 17:00:25 +0200 (CEST) Received: from [::1] (port=42810 helo=web6.sd.eurovps.com) by web6.sd.eurovps.com with esmtp (Exim 4.92) (envelope-from ) id 1iAxuy-00CuXN-EN; Thu, 19 Sep 2019 18:00:24 +0300 Received: from out-23.smtp.github.com ([192.30.252.206]:45043) by web6.sd.eurovps.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iAxup-00CuQD-8Z for flent-users@flent.org; Thu, 19 Sep 2019 18:00:21 +0300 Received: from github-lowworker-2300405.va3-iad.github.net (github-lowworker-2300405.va3-iad.github.net [10.48.17.39]) by smtp.github.com (Postfix) with ESMTP id 59C1766044A for ; Thu, 19 Sep 2019 07:59:34 -0700 (PDT) Date: Thu, 19 Sep 2019 07:59:34 -0700 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: subscribed 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: Subscribed Content-Type: multipart/mixed; boundary="===============5875694804356923447==" 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 --===============5875694804356923447== Content-Type: multipart/alternative; boundary="--==_mimepart_5d8397d64a3db_3b753f83224cd968101862"; charset=UTF-8 Content-Transfer-Encoding: 7bit ----==_mimepart_5d8397d64a3db_3b753f83224cd968101862 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Rich Brown 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 ----==_mimepart_5d8397d64a3db_3b753f83224cd968101862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, view it on GitHub, or mute the thread.

----==_mimepart_5d8397d64a3db_3b753f83224cd968101862-- --===============5875694804356923447== 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 --===============5875694804356923447==--