Re: [Starlink] The "reasons" that bufferbloat isn't a problem

On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink < starlink@lists.bufferbloat.net> wrote: > The RFC is very plausible but the methods break down in multiple ways, > particularly with wifi. > Dave, can you elaborate more on the failures? Are these being researched or addressed in the current

Re: [Starlink] It’s the Latency, FCC

Comments inline. [image: Company logo] *Jeremy Austin* Sr. Product Manager *Preseem | Aterlo Networks* Book a call: https://app.hubspot.com/meetings/jeremy548 1-833-773-7336 ext 718 <18337737336718> *|* 1-907-803-5422 <19078035422> jer...@aterlo.com On Thu, May 2, 2024 at

Re: [Starlink] [LibreQoS] [Rpm] net neutrality back in the news

On Thu, Sep 28, 2023 at 12:09 PM dan via LibreQoS < libre...@lists.bufferbloat.net> wrote: > "(I assume most ISPs want happy customers)." > made me laugh a little. 'Most' by quantity of businesses maybe, but > 'most' in terms of customers being served by puts the Spectrums and > Comcasts in the m

Re: [Starlink] tarana strikes back

I haven’t vetted their specific numbers; but the approach (regarding actual households per square mile) is consistent with mine comparing StarLink with other WISP bands. https://preseem.com/2021/06/fixed-wireless-spectrum-bands/ The upshot is that you can consider the shared medium of RF in terms

Re: [Starlink] [LibreQoS] Enabling a production model

On Wed, Mar 29, 2023 at 6:54 AM dan via LibreQoS < libre...@lists.bufferbloat.net> wrote: > The obvious solution is to foster competition. Anywhere you overlay cable >> companies with fiber BOTH companies remain and compete against each other >> and the cable company increases upload speeds. If

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

On Mon, Mar 13, 2023 at 12:34 PM dan 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 informatio

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

On Mon, Mar 13, 2023 at 10:26 AM dan wrote: If you troubleshoot your ISP based on speed tests you will be chasing your tail. Meanwhile, that internet facing interface can see the true numbers the entire time. The consumer is pulling their full capacity on almost all links routinely even if bri

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

On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink < starlink@lists.bufferbloat.net> wrote: > Hi Dan, > > > > On Jan 9, 2023, at 20:56, dan via Rpm wrote: > > > > You don't need to generate the traffic on a link to measure how > > much traffic a link can handle. > > [SM] OK,

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

On Mon, Jan 9, 2023 at 10:26 AM Dave Taht via LibreQoS < libre...@lists.bufferbloat.net> wrote: > I > > 2) Few are actually testing within-stream latency > > If some kind of consensus can be generated around how latency under load should be reported, and bearing in mind that to date Preseem measur

Re: [Starlink] How I hacked Starlink and got service for free without meaning to

When capitalization matters. JEremy On Fri, Sep 16, 2022 at 3:22 PM Dave Taht via Starlink < starlink@lists.bufferbloat.net> wrote: > You are now the world record holder for uplink. > > On Fri, Sep 16, 2022, 3:45 PM Bruce Perens via Starlink < > starlink@lists.bufferbloat.net> wrote: > >> I have

Re: [Starlink] It's still the latency, starlink!

We will keep preaching it. This also feeds into the frustration around the manipulation of the US (FCC) federal definition of broadband. I care little about a 1000/500 connection with 2000 ms of latency under load; I’d much rather have a 100/20 that never exceeds 100 ms! Jeremy On Sat, Jul 16,