From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 385C13B29E; Mon, 13 Mar 2023 12:09:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678723765; i=moeller0@gmx.de; bh=b6SbCxqxrmWdMJ/08Y4VbJmViui3MmsjsZIm309zPds=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KEVym9QLDvCD37Ec0GLT4Z87JhWtzexKAxd/MWltGByV48gN4LSZvBrwrZz6dY0TL 8cra7miRgRLKPTIiHgafbffLx+L4TdJmgQi6RcudCXKaGZkA363SlYGweU14F7AQ7+ tGTulB0EoY/gnLUx8gTH73qGAyMrKrlMybPsr5cNwxmIyDuQXGvJm4+cVEiVDPi0fd PnrQx54JJg1z04NmoB9f9aVgvfIuNN+KisSvXlsXYMIEdKXa5eQ7rXEosfpNwgVBpB 3Q3VWRQjOT5YdD717RGdpr63+P+vao2TwlqebnL+wbaJDMjQZ/NvGRS9ME8AzB76QF wjEbo/J3CY16w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MNKhs-1puwJS45IA-00OqSo; Mon, 13 Mar 2023 17:09:25 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 13 Mar 2023 17:09:23 +0100 Cc: Jeremy Austin , Dave Taht via Starlink , dan , libreqos , Rpm , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <45AA2C67-CC59-4222-991C-F43D08699F90@gmx.de> References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:pjdnBaVUzI1x2tZr1TWGvZaFluhuwzFRzkoxdeAxR4xP+LZnNZL gmxl8CpWqoITNJBt3k8djbQC+H0R4xgZ6aJCvr0X8RsI3bmN9dox8Arbs1V2dYNU9n97hK7 L7IfUaBeJo54RslvYMfgv0/NxW14KDcMXKEnj/Yd7o9Xa9RGjkiwI5gu/gnnGB4gJLEp237 ImJODQSKFpBu3IkKLRXNw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:FNOro5NvKQc=;F1dSKIL3Sk31OXuypRQRXJ00C4w IIsbcu2d8zoRhkds4LW9IEXB1bAbPuXn3SXEranyPIKSjCUtc6wJFIfiKdo9PPgZ1HqBjFm5c gDTdkfo8ngMzLCyW3FIfm9aw5rA2GKSeVfyFI5t9+TKrN3l1BD/CF+M8VWdSajJ0cM6Z/XFWo 3KCgJ5LHzDzbjhVDyTTLzTaknl3B4Wt3PHBY2K37ASndYHRErKmQb/kBiBKtIoo4GCL594wm7 9eQHU7a5SKDVc10vsngzTD1e4f2azkqduEFTP0e89iUdJz009rkEeYe0dFRJLtEErrsTGu0jG 8OfSn8ybfiCs7bVo9WO1VeoVDjyt2qdOUHSB7XUNUtXmd5kEmXRMtPtZp6haK68Avoz1QtO33 BXOFOHQ43PF9C94AqQib6tvDQUQXCGx1Po9/XW53tHvuYUwMNSAXmWGpX/2XWiWdm+vb456g1 ZZOPQ8Yk38YA08W3/4fUKSIB4VwzjzQ4s9llAgxNBfCh8DHU80kj22Kblgkjbgfeh41/gG081 s0QV1y1hyLTduNRJ3q6ZA2decIo3RLpBpF7l0jyoeNb16LE5jA5QI+ilMXAD27wKAwgJA6nl/ OxRbhKxDyYK8mO9ZrLQv4jOSbnhHwqPcCfVIYR2SgUwhAeVZ61beBq1yGQwNzyJxVMbXmEGy7 GkdmftWBkPhsGxbNHiSJz4JepkRf5pYFthfwnRwPT8Ak6LKM0of9Fwdy/JiPUJkIDENhXZitn gjhdcstGw4O8FtRUXM/tDBGueC8S3K3Hf7eaeqabLS+PNW3XJ1LWcQIN8zOQbmaTzp4uQ4qZJ of9j8mPrtgRNy7efRzLCs87CrPyHUrvoGsMlL1dCyk/LlaQuZUDEPBJUyB91TK+vGla55QHLY V3UnJJmvWi340qD0SyrZ2uhb/X7//bHJ2Et7mlOy7v7Qwxk13zpiSJmNtNWGXA5VaxPZ4jYBS MjfkgVJdbPwB0k2NLeUJw/eLb/g= Subject: Re: [Rpm] UnderBloat on fiber and wisps X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 16:09:27 -0000 > On Mar 13, 2023, at 17:04, Dave Taht wrote: >=20 > On Mon, Mar 13, 2023 at 8:08=E2=80=AFAM Jeremy Austin via Rpm > wrote: >>=20 >>=20 >>=20 >> On Mon, Mar 13, 2023 at 3:02=E2=80=AFAM Sebastian Moeller via = Starlink wrote: >>>=20 >>> Hi Dan, >>>=20 >>>=20 >>>> On Jan 9, 2023, at 20:56, dan via Rpm = wrote: >>>>=20 >>>> You don't need to generate the traffic on a link to measure how >>>> much traffic a link can handle. >>>=20 >>> [SM] OK, I will bite, how do you measure achievable = throughput without actually generating it? Packet-pair techniques are = notoriously imprecise and have funny failure modes. >>=20 >>=20 >> I am also looking forward to the full answer to this question. While = one can infer when a link is saturated by mapping network topology onto = latency sampling, it can have on the order of 30% error, given that = there are multiple causes of increased latency beyond proximal = congestion. >>=20 >> A question I commonly ask network engineers or academics is "How can = I accurately distinguish a constraint in supply from a reduction in = demand?" >=20 > This is an insanely good point. In looking over the wisp > configurations I have to date, many are using SFQ which has a default > packet limit of 128 packets. Many are using SFQ with a *even shorter* > packet limit, which looks good on speedtests which open many flows > (keown's sqrt(flows) for bdp), but is *lousy* for allowing a single > flow to achieve full rate (the more common case for end-user QoE). >=20 > I have in general tried to get mikrotik folk at least, to switch away > from fifos, red, and sfq to wards fq_codel or cake at the defaults > (good to 10Gbit) in part, due to this. >=20 > I think SFQ 128 really starts tapping out on most networks at around > the 200Mbit level, and above 400, really, really does not have enough > queue, so the net result is that wisps attempting to provide higher > levels of service are not actually providing it in the real world, an > accidental constraint in supply. >=20 > I have a blog piece, long in draft, called "underbloat", talking to > this. Also I have no seen multiple fiber installs that had had a > reasonable 50ms FIFO buffer for 100Mbit, but when upgraded to 1gbit, > left it at 5ms, which has bad sideffects for all traffic. >=20 > To me it looks also that at least some ubnt radios are FQd and = underbuffered. This is why I tend to describe bufferbloat as a problem of = over-sized and under-managed buffers hoping to imply that reducing the = buffersize is not the only or even best remedy here. Once proberly = managed large buffers do no harm (except wasting memory for most of the = time, but since that buys some resilience that is not that bad). Regards Sebastian P.S.: This is a bit of a pendulum thing where one simplistic "solution" = too-large-buffers gets replaced with another simplistic solution = too-small-buffers ;) >=20 >> -- >> -- >> Jeremy Austin >> Sr. Product Manager >> Preseem | Aterlo Networks >> preseem.com >>=20 >> Book a Call: https://app.hubspot.com/meetings/jeremy548 >> Phone: 1-833-733-7336 x718 >> Email: jeremy@preseem.com >>=20 >> Stay Connected with Newsletters & More: = https://preseem.com/stay-connected/ >> _______________________________________________ >> Rpm mailing list >> Rpm@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm >=20 >=20 >=20 > --=20 > Come Heckle Mar 6-9 at: https://www.understandinglatency.com/ > Dave T=C3=A4ht CEO, TekLibre, LLC