Hi Jeremy,
> On Mar 13, 2023, at 20:52, Jeremy Austin <[email protected]> wrote:
>
>
>
> On Mon, Mar 13, 2023 at 12:34 PM dan <[email protected]> wrote:
>
> 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.
>
> 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):
>
> 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.
>
> 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
>
> --
> --
> Jeremy Austin
> Sr. Product Manager
> Preseem | Aterlo Networks
> preseem.com
>
> Book a Call: https://app.hubspot.com/meetings/jeremy548
> Phone: 1-833-733-7336 x718
> Email: [email protected]
>
> Stay Connected with Newsletters & More: https://preseem.com/stay-connected/
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
