<html><body><div dir="ltr">
I’m sticking to my guns on this, but am prepared to let this particular argument rest. The threads is approaching unreadable.</div><div dir="ltr"><br></div><div dir="ltr">Let me throw something else out there. It would be very nice to have some standard packet type that was designed to be mangled by a traffic shaper. So you could initiate a speed test specifically to stress-test the link and then exchange a packet that the shaper would update both ways with all the stats you might want. Ie, speed test is getting 80Mbps but there’s an additional 20Mbps on-link so it should report to the user that 100M aggregate with the details broken out usably. Could also report to that speed test client and server things like latency over the last x minutes along with throughput so again, could be charted out to show the ‘good put’ and similar numbers. Basically, provide the end user with decently accurate data that includes what the speed test app wasn’t able to see itself. It could also insert useful data around how many packets arrived that the speed test app(s) could use to determine if there are issues on wan or lan. </div><div dir="ltr"><br></div><div dir="ltr">I say mangle here because many traffic shapers are transparent so the speed test app itself doesn’t really have a way to ask the shaper directly. </div><div dir="ltr"><br></div><div dir="ltr">My point in all of this is that if you’re giving the end user information, it should be right. No information is better than false information. End users will call their ISP or worse get on social media and trash them because they bought a $29 netgear at Walmart that is terrible.</div><div dir="ltr"><br></div><div dir="ltr">After all the entire point if all of this is end-user experience. The only benefit to ISPs is that happy users are good for business. A lot of the data that can be collected at various points along the path are better for ISPs to use to update their networks to improve user experience, but aren’t so useful to the 99% of users that just want low ‘lag’ on their games and no buffering.<br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><br><br></div></div><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mar 13, 2023 at 3:00:23 PM, Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
<div>
<div>
Hi Jeremy,<br><br><blockquote type="cite"> On Mar 13, 2023, at 20:52, Jeremy Austin <<a href="mailto:jeremy@aterlo.com">jeremy@aterlo.com</a>> wrote:<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> On Mon, Mar 13, 2023 at 12:34 PM dan <<a href="mailto:dandenson@gmail.com">dandenson@gmail.com</a>> wrote:<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> See, you're coming around. Cake is autorating (or very close, 'on<br></blockquote><blockquote type="cite"> device') at the wan port. not the speed test device or software. And<br></blockquote><blockquote type="cite"> the accurate data is collected by cake, not the speed test tool. That<br></blockquote><blockquote type="cite"> tool is reporting false information because it must, it doesn't know<br></blockquote><blockquote type="cite"> the other consumers on the network. It's 'truest' when the network is<br></blockquote><blockquote type="cite"> quiet but the more talkers the more the tool lies.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> cake, the kernel, and the wan port all have real info, the speed test<br></blockquote><blockquote type="cite"> tool does not.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> 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): <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Consumers use speed tests to qualify their connection.<br></blockquote><br> [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.<br><br><blockquote type="cite"> <br></blockquote><blockquote type="cite"> 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.<br></blockquote><br> [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. ;)<br><br><blockquote type="cite"> 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.<br></blockquote><br> [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.<br><br><blockquote type="cite"> And yes, Preseem does have an iron in this fire, or at least a dog in this fight.<br></blockquote><br> [SM] Go team!<br><br><blockquote type="cite"> 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.<br></blockquote><br> [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.<br><br>Regards<br> Sebastian<br><br><br><blockquote type="cite"> <br></blockquote><blockquote type="cite"> -- <br></blockquote><blockquote type="cite"> --<br></blockquote><blockquote type="cite"> Jeremy Austin<br></blockquote><blockquote type="cite"> Sr. Product Manager<br></blockquote><blockquote type="cite"> Preseem | Aterlo Networks<br></blockquote><blockquote type="cite"> <a href="http://preseem.com">preseem.com</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Book a Call: <a href="https://app.hubspot.com/meetings/jeremy548">https://app.hubspot.com/meetings/jeremy548</a><br></blockquote><blockquote type="cite"> Phone: 1-833-733-7336 x718<br></blockquote><blockquote type="cite"> Email: <a href="mailto:jeremy@preseem.com">jeremy@preseem.com</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Stay Connected with Newsletters & More: <a href="https://preseem.com/stay-connected/">https://preseem.com/stay-connected/</a><br></blockquote><br>
</div>
</div>
</blockquote>
</div></body></html>