From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 ACD5F3B2A4 for ; Wed, 31 Aug 2022 10:52:37 -0400 (EDT) Received: by mail-wr1-x42d.google.com with SMTP id v16so15881636wrm.8 for ; Wed, 31 Aug 2022 07:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=z0FtZww1Bm127FC+9+d8jEfpIuqrStmsZ1dzO2u6ljo=; b=IXtSa7+YMKWDQ/PWcn0XJkqc8RBkR+A6/Z75jEad5gBdnW+b0foD0woGYWChgbUNTD H3n6XwqMgwqmT118djBNNFRxPgNkydRR5rIlOk6zv7I2cuTBCdcqzTmmgu8EMi0mwMOg 4dwqLgRsr5CjVTqLjT3gUmqesFmfT1kc1Qlr77/cfJCJD89M7JZaS7+5p5nPD+3wYAnv gh/KiO8ef3cwIoQb0501GXAksvnK5JYn5MMumBLuewn2BtJTLxwFuOT8AP/cUFPH5G9i A2qsYsWCV9MedvXuiL0WSJ6CYtHQwhPTO/gv69e6yeirOZ2VccqxwWKASAFDAOe3C+9r jzJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=z0FtZww1Bm127FC+9+d8jEfpIuqrStmsZ1dzO2u6ljo=; b=upitXg4lrvxos3WK8DDoV9vhvDV+6lNQ5CPhhxUvyTT5G0piazl0IQIf1/i5WjEZ0L GIu/6bjm0fPVwiZ3zKu0gQni7mr4Z79RAFC0jKL7m3QAjLL36cGi8h44mowxPGyWeFJI MXl/qG1AdWfK5orwDhtvDZ1/9BIK3cNjtzeNhVNcbCprI8BZjhYQCnn0oQ+J7/7X8xDp QN5yovxorOnFxxQyaJFrhYNmmBi4I4BpHT4UH5oOEAOCdRsvKAIM2HtJl+GkteWRIw9Q tj2TUixgLTW32w+ucGGNSsFzf7L54mXbieSv8YLDRYs82nmjAWCwWcdqVmna2t1QyMEC 0s0w== X-Gm-Message-State: ACgBeo3rC4iTT4fbth+ZX3AE2nu3d0l9G6LRCKvH+995FH7TBF45OkIc xCvpxNJ5QOoqg1qEZOW9Iil74ZM30UiRm4mWB/CcZd+LI3U= X-Google-Smtp-Source: AA6agR7/nIs+lT3Rbi5V12ylG5c/EKm1k8lrjuntMLFylDuxpalhDZwTck7FGKLQjTb1UaPxUHkxJS2moZKUgA6H/Pk= X-Received: by 2002:a05:6000:1549:b0:225:652e:45d4 with SMTP id 9-20020a056000154900b00225652e45d4mr12477431wry.15.1661957556372; Wed, 31 Aug 2022 07:52:36 -0700 (PDT) MIME-Version: 1.0 References: <1661878433.14064713@apps.rackspace.com> In-Reply-To: <1661878433.14064713@apps.rackspace.com> From: Dave Taht Date: Wed, 31 Aug 2022 07:52:23 -0700 Message-ID: To: "David P. Reed" Cc: Dave Taht via Starlink Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] Starlink "beam spread" 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, 31 Aug 2022 14:52:37 -0000 On Tue, Aug 30, 2022 at 9:53 AM David P. Reed via Starlink wrote: > First, it's worth looking at all the problems currently in WiFi performan= ce when you share an AP with multiple active stations using 100's of Gb/s o= n the average (not just occasionally). > > Dave - you tried in "make-wifi-fast", and the architecture gets in the wa= y there. (yeah you can get point to point gigabit/sec single file transfers= , but to do that you invoke features that destroy latency and introduce hug= e variability if you share the AP at all, for these reasons). Didn't "try", did. :) https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/830 Also managed the "high variability" problem to a large extent, being able to 'slide' servicing sparse stations into that budget. ... If you consider being able to effectively multiplex 4 stations at full load in both directions with under 30ms of queuing "good". Many APs to this day, including enterprise ones, are behaving a lot more like our initial results on that link above (if y'all scroll back), but at least test houses like candelatech have tcp test suites for multistation behaviors now and are feeding those back to the vendors. It's very possible to do 100x better than that (call it 300us) in wifi with proper hardware support. WiFi 7 holds the promise of multiple stations being able to transmit on their own subchannel, which I will love if they can make it work, but it has many flaws like "sounding". > > > Starlink is a good "last resort" service as constituted. But fiber and la= st few-hundred meters wireless is SO much better able to deliver good Inter= net service scalably. Starlink just has to be better than old DSL to succeed. It is, except it's unusable for fps gaming. > Even that assumes fixing the bufferbloat that the Starlink folks don't se= em to be able to address... It's been better lately on uploads. At the lowest tier of service "idle", ~2mbit, it's rather sane. Only when it gets "full" bandwidth from the controller does it get past 150ms now. My guess is it's a tail drop per packet queue, dynamically controlled. Not cake, no fq to be seen, way too much queuing in one direction or another at the higher rates. I basically shaped it to 6mbits up to avoid that behavior and only notice a sat switch when it messes with my mosh or videoconference. Done that way it's been a lot better than cell was. Some other data: is you can always get a small flow through at 20ms intervals nowadays, however, if you attempt to send stuff at 10ms or 5ms intervals I've seen as high as 14% packet drop. I do not understand how that correlates back to service intervals or their uplink *at all*. > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_code= l/ Dave T=C3=A4ht CEO, TekLibre, LLC