From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 73A2A3B29E; Mon, 13 Mar 2023 15:34:06 -0400 (EDT) Received: by mail-yb1-xb35.google.com with SMTP id i6so13130387ybu.8; Mon, 13 Mar 2023 12:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678736046; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AxkcAbx2usiD9edzG/fEcZf0UlMnqru9lgd82LN7lgk=; b=e4Ao4TzJaqwgovxqPMos2GbXiYXTW6apELO7BSoj7AHx2Vzt+6nb0RVEQkt4t3wjKe 6gaA8LTnDnV6nka4sS0rJtPbtIDx6i+g+iF3mrYHRuPnKKN+xbCKx/iACwDLb6J451zX yDgpeKKcZHwbeBdyc9PZKtzeJSAjpT0pblOEVij2HIXeFw24bbD68gwfjkNOzyzYLf7L OVQb90hoiCogsfBmZJk0LirEiibzhWJzB3jbNMRXYb7FLB4m9jCtlOcUiQ1fL1wq/X2x 2nWZlx+3B+FXm9DH/uZPwxhnL67cPix2HGyh57MUiYkjkjUewI20wDBl3BYbcPSdxTNh F0SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678736046; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AxkcAbx2usiD9edzG/fEcZf0UlMnqru9lgd82LN7lgk=; b=qWVq1VV/Djwr4kM4v8xsVQrPH0zeKj4goF428TS7ROCY06r8Kkj4oKSAjpDCyiqI+E EfMgQzhCwOvzErn4aBtMGGRqg+iM1sreX3o+OehYF2pmMqqfWXlS+gyquU498WbLnCOV YTV+hJe2SJERj6Wco4641qmIVLw/fEECuBSSYeRkMZKFYa/CeoENw1sLhKBrJrxdRueL tPWd7JW2ZoQnNbXEhuvD+Wpjw1cy9lEKXmxt+5SrcH9T4FUS74i5bwIgcmILrsekWNTi s3PMqNmuAIfNWL6tiOW60e6DlQqPuqpRpzgJvYxDpAYvfCHlF5LAifoT4UH5YtyHjIfv Iq8g== X-Gm-Message-State: AO0yUKU65rbqNCgxTCZuSQ7A2TCLzaajHs53PPDKODOrxGe+9qYO3sgZ VYs9HEyp1ls+Oilba83hh1p7RTpRzH57LH+lLZ+q4Dlw X-Google-Smtp-Source: AK7set9S0M01eowkhUmerjMnmvctLb6pqtX2WA1wHVBGrZ7860Mrc9XU+9dQln56whUfAVycNYZBuSPWpyuL7Lnit9o= X-Received: by 2002:a05:6902:188:b0:a99:de9d:d504 with SMTP id t8-20020a056902018800b00a99de9dd504mr21726905ybh.12.1678736045610; Mon, 13 Mar 2023 12:34:05 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <22C819FA-DDD7-4B9B-8C09-8008D4273287@gmx.de> From: dan Date: Mon, 13 Mar 2023 13:33:54 -0600 Message-ID: To: Sebastian Moeller Cc: Jeremy Austin , Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 19:34:06 -0000 > > I respectfully disagree, if say, my modem had a 4 GB queue I coul= d theoretically burst ~4GB worth of data at line rate into that buffer with= out learning anything about the the modem-link capacity. so this is where we're getting into staw man arguments. Find me a single device or shaper with a 4GB buffer and we'll talk. > > > > turn off the > > shaper and run anything. run your speed test. don't look at the > > speed test results, just use it to generate some traffic. you'll find > > your peak and where you hit the buffers on the DSL modem by measuring > > on the interface and measuring latency. > > Peak of what? Exactly? The peak sending rate of my router is well= known, its 1 Gbps gross ethernet rate... I don't know how I can say it any clearer. there is a port, any speed. data flows across that port. The peak data flowing is the measure. simultaneously measuring latency will give the 'best' rate. so called 'goodput' which is a stupid name and I hate it but there it is. > > > > That speed test isn't giving > > you this data and more than Disney+, other than you get to pick when > > it runs. > > Hrm, no we sre back at actually saturating the link, which we're doing all the time. it's the entire premise of QoE. Links get saturated, manage them. > > > [SM] not really, given enough capacity, typical streaming protoco= ls will actually not hit the ceiling, at least the one's I look at every no= w and then tend to stay well below actual capacity of the link. Not sure where you're getting this info, I'm looking right at customers on everything from 25Mbps to 800Mbps plans. And again, I'm not saying you can saturate the link intentionally, I'm saying that the tool doing the saturation isn't actually giving you accurate results. You have to look at the interface and the latency for the results. The speed test is a traffic generator, not a measuring tool. It's fundamentally cannot do the measuring, it's doesn't have the ability to see other flows on the interface. > > > [SM] But my problem is that on variable rate links I want to meas= ure the instantaneous capacity such that I can do adaptive admission contro= l and avpid over filling my modem's DSL buffers (I wish they would do somet= hing like BQL, but alas they don't). Literally measure the interface on a schedule or constantly and you're getting this measurement every time you use the link. and if you measure the latency you're constantly finding the spot right below the buffers. > > [SM] With competent AQM (like cake on ingress and egress configur= ed for per-internal-IP isolation) I do not even notice whether a speedtes r= uns or not, and from the reported capacity I can estimate the concurrent lo= ad from other endhosts in my network. exactly. EXACTLY. You might just be coming around. That speed test was held back by the shaper for your benefit NOT the speed test's. It's results are necessarily false. YOU can estimate the capacity by adding up the speedtest results and your other uses. Measuring the outside interface gives you exactly that. the speed test does not. it's just a traffic generator for when you aren't generating it on your own. > > > > Speed test cannot return actual capacity > > [SM] Conventional capcaity tests give a decent enough estimate of= current capacity to be useful, I could not care less that they are potenti= al not perfect, sorry. The question still is how to estimate capacity witho= ut loading the link... you have to load the link to know this. Again, the speed test is a traffic generator, it's not a measuring tool. You have to measure at the wan interface to know this, you can never get it from the speed test. And no, the speed test isn't a decent enough estimate. The more important the data is to you the more likely the test is bad and going to lie. Internet feeling slow? run a speed test and put more pressure on the service and the speed test has less available to return results on, all the other services getting their slice of the pie. > > > > Guess what the only way to get an actual measure of the capacity is? > > my way. measure what's passing the interface and measure what happens > > to a reliable latency test during that time. > > [SM] This is, respectfully, what we do in cake-autorate, but that= requires an actual load and only accidentally detects the capacity, if a h= igh enough load is sustained long enough to evoke a latency increase. But I= knew that already, what you initially wrote sounded to me like you had a m= ethod to detect instantaneous capacity without needing to generate load. (B= TW, in cake-autorate we do not generate an artificial load (only artificial= /active latency probes) but use the organic user generated traffic as load = generator*). > > *) If all endhosts are idle we do not care much about the capacity, only = if there is traffic, however the quicker we can estimate the capacity the t= igher our controller can operate. > 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. cake, the kernel, and the wan port all have real info, the speed test tool does not.