I am not sure if dan luu has also twigged that bufferbloat was a root cause of his web problems, here: https://danluu.com/web-bloat/ On Tue, Mar 15, 2022 at 5:51 PM Dave Taht wrote: > yes, they did seem to reduce the excessive buffering and load swings on > the download to saner sizes back in august or so. 250ms of added latency is > about 5-10x more than they need tho, and hurts all interactive applications > like gaming or videoconferencing. Anything more than 250ms tends to start > "breaking the internet", as many of our protocols start timing out then and > send more packets, which eventually ends in congestion collapse.... > > > On Tue, Mar 15, 2022 at 5:47 PM Nathan Owens wrote: > >> Here’s what it looks like for a sustained download: >> https://i.redd.it/odo31ofu4t971.png >> This was from a while ago, most of those latency spikes have been >> dampened. >> >> On Tue, Mar 15, 2022 at 3:39 PM Dave Taht wrote: >> >>> On Tue, Mar 15, 2022 at 5:09 PM Daniel AJ Sokolov >>> wrote: >>> > >>> > Hello, >>> > >>> > From this list I have learned that Starlink is optimized to shine in >>> > tests with speedtest.net and similar sites, but that transmission >>> rates >>> > drop quickly after about 15 seconds. >>> >>> That is not strictly true. The trend is a low rate for the initial >>> 15s, then a boost, then variable. It happens that speedtest reports >>> the *last* result in the typically 20s it runs, >>> so by that light is starlink is "optimized for speedtest". Much of the >>> internet is "optimized for speedtest", tons of services basically blow >>> up classic tcp congestion controls at T+21s. >>> >>> Attached are two example flent test runs, a rrul test from one project >>> member's dishy, and a tcp_nup test from anothers. >>> >>> For reference also attached is how a present day WISP 60Ghz radio >>> functions, one which has FQ and AQM, with consistent bandwidth, and >>> only ~5ms latency swings. Ideally the latency on starlink would not go >>> over 10ms their baseline ~40ms latency, under these loads. >>> >>> Comparing the later two tests you can see the inversions between >>> bandwidth and latency that come from the fixed length fifos starlink >>> uses at any of the roughly 3 >>> speed settings we currently see. >>> >>> PS - most web pages cannot use more than 25MBit in the 3s they typically >>> take. >>> >>> > How do they do that, technically? >>> >>> Allocate bandwidth? Unknown. Ever 15s seems silly. Not modifying queue >>> length and/not using a smarter queuing algo like fq_codel or cake when >>> they do change the bandwidth allocation is the simple flaw in their >>> design I keep hoping they'll fix. >>> >>> > >>> > Is that a result of Bufferbloat? >>> >>> Yes. The rrul test is often illustrative of the problem on how slowly >>> the internet operates during an upload clogging up the queue, or vice >>> versa. Most ISPs do some sort of ack filtering or prioritization to >>> make uploads interfere less with downloads, or use AQM, fq or a >>> combination of both. >>> >>> > Is that a a specific code in the modem >>> > to cheat, like some car manufacturers cheated on emissions tests? >>> >>> I hope not. No, they do have limited capacity, do have to change sats, >>> do need to allocate bandwidth sanely. AND buffering. >>> >>> > Is >>> > that something done in the satellites who shift capacity from other >>> > users to those users who initiate downloads? Is that done on the >>> backhaul? >>> >>> Wish we knew. In my ideal world they would supply a statistic that a >>> sch_cake could take and vary the rate/buffering based on that on the >>> home router, or just do it more right >>> in the dishy and head ends with cake + BQL. >>> >>> > >>> > Thank you >>> > Daniel >>> > _______________________________________________ >>> > Starlink mailing list >>> > Starlink@lists.bufferbloat.net >>> > https://lists.bufferbloat.net/listinfo/starlink >>> >>> >>> >>> -- >>> I tried to build a better future, a few times: >>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org >>> >>> Dave Täht CEO, TekLibre, LLC >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink >>> >> > > -- > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > Dave Täht CEO, TekLibre, LLC > -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC