From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 22C1A3B29E; Mon, 13 Mar 2023 17:00:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678741224; i=moeller0@gmx.de; bh=lGCqSSdjL0gS/rHOkpkarG4uXMNGad1kTQ5FZ3C4q+0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=eAHErxLmBi/7TxT4VIrP4QjBJ5kOu1fibG3nkE1T8coz2qe0CK/JqQanptopKWH33 LANyacHCXhw283XhaC3TIXrSUhwbTYEtz+f0M3mpV0EhzcKf10tueKr6BvWXr9EzMP 0r9ma/ZYvu7kCmAeJIfrVj53XxaZu2EDDrhUOZYCyS9iPTRFFed007lrSR1e6SK21+ QpvQloL9kipvtZZM/AzL7L6YM+7OPJZkw2ygz0OX1CP8AqDsqIHflJ+LMO+A2Hxfw4 d+OjZB3vTnHd+T4yO8NV6sKxqDNr4fUqacONEn8eI4OzBU2MT7FQzS+Y7aTiS1fZbm G3YZl4wWTrolw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.112.228.62]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M4b1y-1paAaH3mxK-001lqD; Mon, 13 Mar 2023 22:00:23 +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 22:00:23 +0100 Cc: dan , Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> <3CD0B9E6-0B2A-4A70-8F53-ED0822DF77A6@gmx.de> <13DE6E53-665F-4C20-BBE2-70E685421E9D@gmx.de> <22C819FA-DDD7-4B9B-8C09-8008D4273287@gmx.de> To: Jeremy Austin X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:PqZjUIL45w+dIrWRijV9K5s75O2KLOW42TjbKkWPRHXEgMPq8Pm vCIAF2z5d+RjeujJecIgS2sESIiZia0QrE0EfAfgLitn3CpWnww2gKt/XSZT2Q58CfMARdp U6/wkj0TNJNk9kkrTKoDAEnWGvSnko8n5SNUIBo7tnr7/StAjnYItJJ3WOo3OQe9/tta7Sr 1bgHLX2i6IqWIwuxsaoeA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:x7819dtlrhQ=;bhCgQrHqemdsFYGhPLkWgaEqEdh Ajbnb8uYiV/ZA0ayLcFdYq5f4ZRXFgjbEo0ouILNIJiqqR6pHhf37O6zLck7Z25/bvsOvHVU3 q0JOV/2XNBlY5HKoCwnQVEH5foBJ72K8dtMwKNsH8g6vui6hsmtZ7zc0hWPCF1id7JmvY1vDU 0pryvxIA6YrrHDfYkROv7yjFppSJQk74KpIS1LAATGYxdKrFwiu7ollttHIby7Oh3ybF3GqtE UlgoZ3UtJLTAorkLQJZAeV2tM+tIpWOv1u7/Ro1/ONc55zwdXPvPJndZZiwU+9uQjx4kVJZtp uxhAA7qy/dn6kEKYV4pb+UuAgmJT5ekfo8269490Uodrv4ybXFCEwxiljaQ8BjS3+SySX5Slk QLx7cHJUFpUP5iAeQqih2/rMHGbpcU3gmVbTCInOKjmfEFjaMhweNV02x+LEipx+AkzVaeqns KCe7hAbiVTJ/4m9h/E4zAUrE5/C3LSvgx3sWGm7qikYBdTOi4w5s9bUKFAB3zie0rtRU4kH2+ Vl3DR64RwYrSCsW6wfmW44wMbbn9afSfEECZL6ehFpTlwLCYOhi07XSl0y7U3pAlO7d5O2ROT pjgr+OZftlubVYgTWnjOl6DWzxUDh49tdD9JHYKXI2OBh1XP5D3Bdkv11ZCsiH/pPuprGk3VR MercEgv9rreHhvZQfyWFLycw+sbap+EPSnnVIJrrxQb4+amcRW9swDk/vBl4KE7rjfOlaiKFA TeppAUcyCK0woOHVqAtYRLRTqgEzBCj9eStRFaJuSKPhxkYRfV2vXx/gS1uGu8Sqpivk2dgWD UHw//CmyRR7MgY/zSClhIIK22zHuHw4bWF9FMdjA+gFS64B5Fx3zwuthH5S4tOO/CVKC9gTAL 5PyPwKEpJm63TeTlZ7HvC5uw8MkOPqhTRmRfRGx/kizMuP9ujMgPZn2MhS0VxYUBqNc0iQycy XVGimw== Subject: Re: [LibreQoS] [Starlink] [Rpm] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 21:00:29 -0000 Hi Jeremy, > On Mar 13, 2023, at 20:52, Jeremy Austin wrote: >=20 >=20 >=20 > On Mon, Mar 13, 2023 at 12:34=E2=80=AFPM dan = wrote: >=20 > See, you're coming around. Cake is autorating (or very close, 'on > device') at the wan port. not the speed test device or software. And > the accurate data is collected by cake, not the speed test tool. That > tool is reporting false information because it must, it doesn't know > the other consumers on the network. It's 'truest' when the network is > quiet but the more talkers the more the tool lies. >=20 > cake, the kernel, and the wan port all have real info, the speed test > tool does not. >=20 > I'm running a bit behind on commenting on the thread (apologies, more = later) but I point you back at my statement about NTIA (and, to a = certain extent, the FCC):=20 >=20 > Consumers use speed tests to qualify their connection. [SM] And rightly so... this put a nice stop to the perverse = practice of selling contracts stating (up to) 100 Mbps for links that = never could reach that capacity ever, now an ISP is careful in what they = promise... Speedtest (especially using the official speedtest app that = tries to make users pay attention to a number of important points, e.g. = not over WiFi, but over an ethernet port that has a capacity above the = contracted speed) seem to be good enough for that purpose. Really over = here that is the law and ISP still are doing fine and we are taking low = single digit thousands of complaints in a market with ~40 million = households. >=20 > Whether AQM is applied or not, a speed test does not reflect in all = circumstances the capacity of the pipe. One might argue that it seldom = reflects it. [SM] But one would be wrong, at least the official speedtests = over here are pretty reliable, but they seem to be competenyly managed. = E.g. users need to put in the contracted speed (drop down boxes to the = select ISP and contract name) and the test infrastructure will only = start the test if it managed to reserver sufficient capacity of the test = servers to reliably saturate the contracted rate. This is a bit of = engineering and not witchcraft, really. ;) > Unfortunately, those who have "real info", to use Dan's term, are = currently nearly powerless to use it. I am, if possible, on both the ISP = and consumer side here. [SM] If you are talking about speedtests being systemicly wrong = in getting usabe capacity estimates I disagree, if your point is that a = sole focus on this measure is missing the way more important point od = keeping latency under load limited, I fully agree. That point currently = is lost on the national regulator over here as well. > And yes, Preseem does have an iron in this fire, or at least a dog in = this fight. [SM] Go team! > Ironically, the FCC testing for CAF/RDOF actually *does* take = interface load into account, only tests during peak busy hours, and = /then/ does a speed test. But NTIA largely ignores that for BEAD. [SM] I admit that I have not looked deeply into these different = test methods, and will shut up about this topic until I did to avoid = wasting your time. Regards Sebastian >=20 > --=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/