> > I respectfully disagree, if say, my modem had a 4 GB queue I could > theoretically burst ~4GB worth of data at line rate into that buffer without > 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 protocols > will actually not hit the ceiling, at least the one's I look at every now 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 measure > the instantaneous capacity such that I can do adaptive admission control and > avpid over filling my modem's DSL buffers (I wish they would do something > 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 configured > for per-internal-IP isolation) I do not even notice whether a speedtes runs > or not, and from the reported capacity I can estimate the concurrent load > 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 potential > not perfect, sorry. The question still is how to estimate capacity without > 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 high > 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 method to > detect instantaneous capacity without needing to generate load. (BTW, 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 tigher > 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. _______________________________________________ Starlink mailing list [email protected] https://lists.bufferbloat.net/listinfo/starlink
