From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tn-mailgw-03.telenor.no (tn-mailgw-03.telenor.no [153.110.76.6]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 50E6E3B29E for ; Mon, 16 Nov 2020 10:25:54 -0500 (EST) IronPort-SDR: Iy03EkR9exSB2aJzslnfz/KnUhvNF4WR5Q+3SBvaipJOFncmB07L8lzWApf7oOKEpRzNKYMnPU tSC6ldexdV0cQsp2pSRo/hDkBkrKZxMwsSL38wh2Ow5nQpTdu4tXPk1bCfrb7cg2Qgju7enC2E IaKz0S4eNb8QMXfbCK+SySPksqh+uXYgudL6OfTdgicvN/6m35ylk/0aXH4jjyQ6WI+GFbDh9s Z9iDV+kYwtb+7RsteUJi0P4xl2jOwBGO400BTtAqJhrptAxLUsEulPs/c3/7EgqFMxBRJhPhQ1 q3U= X-IronPort-AV: E=Sophos;i="5.77,482,1596499200"; d="scan'208,217";a="65364611" Received: from tns-sko-24-203.corp.telenor.no ([10.179.59.71]) by tn-mailgw-03.corp.telenor.no with ESMTP; 16 Nov 2020 15:25:52 +0000 Received: from TNS-SKO-24-208.corp.telenor.no (10.179.59.76) by TNS-SKO-24-203.corp.telenor.no (10.179.59.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Nov 2020 16:25:52 +0100 Received: from TNS-SKO-24-208.corp.telenor.no ([fe80::b024:7a41:ba33:25b6]) by TNS-SKO-24-208.corp.telenor.no ([fe80::b024:7a41:ba33:25b6%12]) with mapi id 15.00.1497.008; Mon, 16 Nov 2020 16:25:52 +0100 From: To: Thread-Topic: BBR implementations, knobs to turn? Thread-Index: AQHWvCk4fuZ0GUZeA0yszB3/rex4Wg== Date: Mon, 16 Nov 2020 15:25:52 +0000 Message-ID: <1605540351240.98589@telenor.com> Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.181.50.11] Content-Type: multipart/alternative; boundary="_000_160554035124098589telenorcom_" MIME-Version: 1.0 Subject: [Bloat] BBR implementations, knobs to turn? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 15:25:54 -0000 --_000_160554035124098589telenorcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm in the process of replacing a throughput test server. The old server i= s running a 1Gbit Ethernet card on a 1Gbit link and ubuntu. The new a 10Gb= it card on a 40Gbit link and centos. Both have low load and Xenon processo= rs. The purpose is for field installers to verify the bandwidth sold to the cus= tomers using known clients against known servers. (4G and 5G fixed install= ations mainly). What I'm finding is that the new server is consistently delivering slightly= lower throughput than the old server. The old server allows for more re-t= ransmits and has a slightly higher congestion window than the new server. Is there any way to tune bbr to allow for more re-transmits (which seems to= be the limiting factor)? Or other suggestions? (Frankly I think the old server is to aggressive for general purpose use. = It seems to starve out other tcp sessions more than the new server. So for= delivering regular content to users the new implementation seems more bala= nced, but that is not the target here. We want to stress test the radio li= nk.) Regards Erik --_000_160554035124098589telenorcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm in the process of replacing a throughput test server.  The old = server is running a 1Gbit Ethernet card on a 1Gbit link and ubuntu. &n= bsp;The new a 10Gbit card on a 40Gbit link and centos.  Both have low = load and Xenon processors.


The purpose is for field installers to verify the bandwidth sold to the = customers using known clients against known servers.  (4G and 5G fixed= installations mainly).


What I'm finding is that the new server is consistently delivering sligh= tly lower throughput than the old server.  The old server allows for m= ore re-transmits and has a slightly higher congestion window than the new s= erver.


Is there any way to tune bbr to allow for more re-transmits (which seems= to be the limiting factor)?  Or other suggestions?



(Frankly I think the old server is to aggressive for general purpose use= .  It seems to starve out other tcp sessions more than the new server.=  So for delivering regular content to users the new implementation se= ems more balanced, but that is not the target here.  We want to stress test the radio link.)


Regards Erik

--_000_160554035124098589telenorcom_--