From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 47C853CB3E for ; Wed, 29 Nov 2017 09:50:27 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1511967023; bh=2aEImCj86Rma265rg7tK/lOEAa2y7X/SS8aKkkLFP7g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gvCiqo5nNGeQdrTWij1M27yb9cVArbNf1YTPrlv4nX+4zM48H5azP0HEtPic2M5BX 23trtV+JpDFhLo4pDHoVn12a74vhCyzUR3SEzk4sCVBOo2FofQ9+KZoquM9Ve/692Q e/MURIHjRGUUz5L6+yy+2rQNvFAj96QJ0UhNl0WOzFqSRRNFnnlETWeDltaLiYcxCw 5dMJYDCc3QlFC48VDE2BXlrUEuZE/3rj94SeUtzJmFFz2BQx14vNTtJRuozdshqQ71 3imgvl0EM15u5HzSsFJQXfdof49NhykhNhoq/42Q34tw5lChY0e/Ms5GO+nL4LEpv3 CB79rEhZOLhoA== To: Georgios Amanakis , Dave Taht Cc: Cake List In-Reply-To: References: <745FEC66-95A7-40E1-A8FA-57714D3AB6AC@gmail.com> <87zi76xlw5.fsf@nemesis.taht.net> <6F2894AD-87EA-4EFC-918E-625E49EDA977@gmail.com> <87o9nmxcbg.fsf@nemesis.taht.net> <87bmjmxbgw.fsf@nemesis.taht.net> <3FAFACA8-C918-4325-BF80-B7EBB6B9B4A7@gmail.com> Date: Wed, 29 Nov 2017 15:50:22 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1y96swh.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] cake flenter results round 2 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 14:50:27 -0000 Georgios Amanakis writes: > I am troubled by the number of data points flent reports for some pings and > uploads in this setup. A typical ack-filter result, similar to rrul2 I > posted before, looks like this: > Summary of rrul test run 'rrul_cakeeth_ds3_900mbit_45mbit_ack' (at > 2017-11-29 14:37:5 > 5.719180): > > avg median # data pts > Ping (ms) ICMP : 100.29 100.00 ms 337 > Ping (ms) UDP BE : 297.62 100.20 ms 156 > Ping (ms) UDP BK : 409.84 100.20 ms 109 > Ping (ms) UDP EF : 414.94 100.20 ms 121 > Ping (ms) avg : 374.13 100.05 ms 343 > TCP download BE : 206.39 217.48 Mbits/s 301 > TCP download BK : 163.05 163.81 Mbits/s 301 > TCP download CS5 : 206.40 217.50 Mbits/s 301 > TCP download EF : 203.18 215.23 Mbits/s 301 > TCP download avg : 194.75 202.59 Mbits/s 301 > TCP download sum : 779.02 810.36 Mbits/s 301 > TCP totals : 781.55 810.66 Mbits/s 301 > TCP upload BE : 1.86 24.68 Mbits/s 23 > TCP upload BK : 0.15 1.72 Mbits/s 24 > TCP upload CS5 : 0.25 2.26 Mbits/s 30 > TCP upload EF : 0.27 2.15 Mbits/s 29 > TCP upload avg : 0.63 7.59 Mbits/s 36 > TCP upload sum : 2.53 30.38 Mbits/s 36 > > Shouldn't all "# data pts" be ~300? Ideally, yes. However, netperf works by estimating after how many bytes it will need to emit the next data point. If this estimate is wrong (which most often happens at very low bandwidths as you are seeing here), the number of data points can be a lot lower. The average values should still be correct, though; they are calculated at the end of the test as bytes transmitted / test duration. Something similar happens with the UDP results, with the added complication that these can stop entirely when there is packet loss. Flent has recently learned how to support the irtt tool (https://github.com/peteheist/irtt/) for the UDP latency measurements, which emits isochronous latency probes in the same way as the regular ping tool. If you install irtt and use the latest git version of Flent, it should be picked up automatically and used for the UDP ping measurements. -Toke