<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 13, 2023 at 10:26 AM dan <<a href="mailto:dandenson@gmail.com">dandenson@gmail.com</a>> wrote:</div><div dir="ltr" class="gmail_attr"><br>
<br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div class="gmail_attr">
If you troubleshoot your ISP based on speed tests you will be chasing</div></div><div class="gmail_quote"><div class="gmail_attr">
your tail.  Meanwhile, that internet facing interface can see the true</div></div><div class="gmail_quote"><div class="gmail_attr">
numbers the entire time.  The consumer is pulling their full capacity</div></div><div class="gmail_quote"><div class="gmail_attr">
on almost all links routinely even if briefly and can be nudged into</div></div><div class="gmail_quote"><div class="gmail_attr">
pushing more a dozen ways (including a speed test).  The only thing</div></div><div class="gmail_quote"><div class="gmail_attr">
lacking is a latency measurement of some sort.  Preseem and Libreqos's</div></div><div class="gmail_quote"><div class="gmail_attr">
TCP measurements on the head end are awesome, but that's not available</div></div><div class="gmail_quote"><div class="gmail_attr">
on the subscriber's side but if it were, there's the full testing</div></div><div class="gmail_quote"><div class="gmail_attr">
suite.  how much peak data, what happened to latency.  If you could</div></div><div class="gmail_quote"><div class="gmail_attr">
get data from the ISP's head end to diff you'd have internet vs isp</div></div><div class="gmail_quote"><div class="gmail_attr">
latencies.    'speed test' is a stress test or a burn in test in</div></div><div class="gmail_quote"><div class="gmail_attr">
effect.</div></div></blockquote><div><br></div>I cannot upvote this enough. I call speed tests — and in fact any packet injection doing more than a bare minimum probe — destructive testing, and said as much to NTIA recently.<div><br></div><div>The *big problem* (emphasis mine) is that the recent BEAD NOFO, pumping tens of billions of dollars into broadband, has *speedtests* as the "proof" that an ISP is delivering.</div><div><br></div><div>It's one thing to solve this problem at the ISP and consumer level. It's another to solve it at the political level. In this case, I think it's incumbent on ISPs to atone for former sins — now that we know that speed tests are not just bad but actively misleading, we need to provide real tools and education.</div><div><br></div><div>Going back to my previous comment, and no disrespect meant to the CAKE autorate detection: "How do we distinguish between constrained supply and reduced demand *without injecting packets or layer violations*?"<br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>--</div><div>Jeremy Austin</div><div>Sr. Product Manager</div><div>Preseem | Aterlo Networks</div><div><a href="http://preseem.com" target="_blank">preseem.com</a></div><div><br></div><div>Book a Call: <a href="https://app.hubspot.com/meetings/jeremy548" target="_blank">https://app.hubspot.com/meetings/jeremy548</a></div><div>Phone: 1-833-733-7336 x718</div><div>Email: <a href="mailto:jeremy@preseem.com" target="_blank">jeremy@preseem.com</a></div><div><br></div><div><span style="color:rgb(23,43,77);font-family:-apple-system,system-ui,"Segoe UI",Roboto,"Noto Sans",Ubuntu,"Droid Sans","Helvetica Neue",sans-serif;font-size:16px;letter-spacing:-0.08px;white-space:pre-wrap">Stay Connected with Newsletters & More: </span><a href="https://preseem.com/stay-connected/" title="https://preseem.com/stay-connected/" style="color:rgb(0,82,204);font-family:-apple-system,system-ui,"Segoe UI",Roboto,"Noto Sans",Ubuntu,"Droid Sans","Helvetica Neue",sans-serif;font-size:16px;letter-spacing:-0.08px;white-space:pre-wrap" target="_blank"><u>https://preseem.com/stay-connected/</u></a><br></div></div></div></div></div>