From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8DFBE3B2A4 for ; Tue, 15 Mar 2022 23:48:24 -0400 (EDT) Received: by mail-ej1-x635.google.com with SMTP id a8so1571515ejc.8 for ; Tue, 15 Mar 2022 20:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SIZVCjc7UC982fF+LB3O4n4+kfJtqJA/FGlgz2tbE4k=; b=ifZ/HY3Rv46gRmucx1OXhVTSvo59a2IlHZed21EH8eNh/GT5I+oGgR19vtpYrSnvvI tyicUXYb/KiLbgEO2kCPkzyLUYOPsgD7a3vxNdrre8/vf9aNgoilVqn52cjZqNzoDAnN 0repyCyv3ID9pqrldRk1fih1YDdziiDSQ/R2bQYC/LXXR9rcOyTWhOrLp6PIdQ1bmDvC 6x2OeuCB9xHBoS8dg14hZ+XuEn9mXWtNDmmGsm++DgSUJfeCSiTS1zSxgWgXGdh0xaPo jSI50XXhGTG9E2zRJT39hFkFGeAquXWUs7RdQ4G2/3GeeDrMzFTtgqtyRqYEdtS04yxS 2s2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SIZVCjc7UC982fF+LB3O4n4+kfJtqJA/FGlgz2tbE4k=; b=Z4VheCGhH8Ml/zfOJaTkaflcwZjW3K76tbOUcINQP4Qz2BsuqEFQD96G2nZhnOyrNX hyvdKvu2CCox2IecllFBvyCmxfAr9wtb0xiHhMac6HoLbvVMP76R+XJZcgf/E7VDvXOF P1aSkI7ydQystUjsfEPpLW8IPMAmmxLAWl3C3+P7Pa9bJmCtZry3SfJdjDz/S5o5R0xY 340OmlMIYY2mKkPEDsdB30pL95gmUxzvx8Phq0STptlT7i3GLv0D/+VLkarMdrLZqa9g flQ5WYv9CzCJr/+nkqQC4uAM4bbm8WwmC5dUO+8D4cIoE/jXddrDj+ZGuaELQWUCUmc9 D+DQ== X-Gm-Message-State: AOAM533SZt1ug4LfPMygW9cmJDVyRAReRlc+YuhECvA1mxSWCtOfGaiS tMkL86Fsdf7cZAvRr0AhQYPhUG0jDv0HTZi4c88fztq8jMs= X-Google-Smtp-Source: ABdhPJz7bjzDNIBpDrc6z7Fm+8Ytf1XdDX3O9BgN5Em+UskiLtAQha9Cnuj/RatEX3EZK//wVwlXSKc33PHuGRPh+nk= X-Received: by 2002:a17:906:b095:b0:6cf:752c:fb88 with SMTP id x21-20020a170906b09500b006cf752cfb88mr25402898ejy.128.1647402502964; Tue, 15 Mar 2022 20:48:22 -0700 (PDT) MIME-Version: 1.0 References: <08c6ab5c-6a9d-e555-671c-5c59cffcd02d@falco.ca> In-Reply-To: From: Dave Taht Date: Tue, 15 Mar 2022 22:48:10 -0500 Message-ID: To: Daniel AJ Sokolov Cc: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] Optimized for Speedtest? X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2022 03:48:24 -0000 One of the many unknowns is about how starlink schedules uplink and downlink "rates" (e.g to some extent the density of encodings). Is it one or more beam with multiple destinatons on the down? Or ? Toke went deep into how wifi ATF works here: https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k= .html Another big question is how they handle encryption(s), again, how wifi works from my notebook is here: https://blog.cerowrt.org/post/crypto_fq_bug/ (with just how hard it was to get right! I still have 87 blog entries from that era to write up!) I can think of a half dozen different ways they could be modulating the beams to encapsulate all the data! Wifi had crypto baked in late (see above) and i would have started with good crypto first in their case, but "my" solution would have much higher power requirements (spitting own all data, received by all, decrypted by the receivers that could find their segments) than what I think they are actually doing, but without two dishys on the same cell, closely linked in time via gps pps, and refine analog an digital measurements, can't wager a guess at the moment. On Tue, Mar 15, 2022 at 5:48 PM Dave Taht wrote: > > For the historical record, we finally found ways to compensate for the > wildly variable bandwidth wifi can have in 2014, and mainlined into > linux in 2016. > > https://blog.cerowrt.org/post/real_results/ > > Example of ath10k wifi before/after here: > > https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/ > > starlink, on the uplink anyway, seemed straightforward to fix, in > comparison to wifi. > > > On Tue, Mar 15, 2022 at 5:39 PM Dave Taht wrote: > > > > On Tue, Mar 15, 2022 at 5:09 PM Daniel AJ Sokolov wro= te: > > > > > > Hello, > > > > > > From this list I have learned that Starlink is optimized to shine in > > > tests with speedtest.net and similar sites, but that transmission rat= es > > > 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 typicall= y 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 back= haul? > > > > 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=3Dhttps%3A%2F%2Fwww.icei.org > > > > Dave T=C3=A4ht CEO, TekLibre, LLC > > > > -- > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org > > Dave T=C3=A4ht CEO, TekLibre, LLC --=20 I tried to build a better future, a few times: https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org Dave T=C3=A4ht CEO, TekLibre, LLC