[Bloat] [Starlink] [Rpm] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA

[dan]

>
>         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.