[image: Screen Shot 2022-03-16 at 6.47.44 AM.png] I repeated this now, no latency spikes or dips to near 0 every 15s are visible anymore. On Tue, Mar 15, 2022 at 3: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 >> >