From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1B6F13B2A4 for ; Sun, 14 May 2023 02:55:28 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id A946718E549; Sat, 13 May 2023 23:55:26 -0700 (PDT) Date: Sat, 13 May 2023 23:55:26 -0700 (PDT) From: David Lang To: Ulrich Speidel cc: David Lang , "starlink@lists.bufferbloat.net" In-Reply-To: <48b00469-0dbb-54c4-bedb-3aecbf714a1a@auckland.ac.nz> Message-ID: <728orr66-1432-751p-263q-sqopr12s20sq@ynat.uz> References: <0no84q43-s4n6-45n8-50or-12o3rq104n99@ynat.uz> <48b00469-0dbb-54c4-bedb-3aecbf714a1a@auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Starlink] Starlink hidden buffers 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: Sun, 14 May 2023 06:55:28 -0000 On Sun, 14 May 2023, Ulrich Speidel wrote: > On 14/05/2023 10:57 am, David Lang wrote: >> On Sat, 13 May 2023, Ulrich Speidel via Starlink wrote: >> >>> Here's a bit of a question to you all. See what you make of it. >>> >>> I've been thinking a bit about the latencies we see in the Starlink >>> network. This is why this list exist (right, Dave?). So what do we know? >>> >>> 1) We know that RTTs can be in the 100's of ms even in what appear to be >>> bent-pipe scenarios where the physical one-way path should be well under >>> 3000 km, with physical RTT under 20 ms. >>> 2) We know from plenty of traceroutes that these RTTs accrue in the >>> Starlink network, not between the Starlink handover point (POP) to the >>> Internet. >>> 3) We know that they aren't an artifact of the Starlink WiFi router (our >>> traceroutes were done through their Ethernet adaptor, which bypasses the >>> router), so they must be delays on the satellites or the teleports. >> >> the ethernet adapter bypasses the wifi, but not the router, you have to cut >> the cable and replace the plug to bypass the router > > Good point - but you still don't get the WiFi buffering here. Or at least we > don't seem to, looking at the difference between running with and without the > adapter. wifi is an added layer, with it's own problems, eliminating those problems when testing the satellite link is the first step, but it would also be a good idea to take the next step and bypass the router. I just discovered that someone is manufacturing an adapter so you no longer have to cut the cable https://www.amazon.com/YAOSHENG-Rectangular-Adapter-Connect-Injector/dp/B0BYJTHX4P > Put another way: If you have a protocol (TCP) that is designed to reasonably > expect that its current cwnd is OK to use for now is put into a situation > where there are relatively frequent, huge and lasting step changes in > available BDP within subsecond periods, are your underlying assumptions still > valid? I think that with interference from other APs, WIFI suffers at least as much unpredictable changes to the available bandwidth. > I suspect they're handing over whole cells, not individual users, at a time. I would guess the same (remember, in spite of them having launched >4000 satellites, this is still the early days, with the network changing as more are launching) We've seen that it seems that there is only one satellite serving any cell at one time. But remember that the system does know how much usage there is in the cell before they do the handoff. It's unknown if they do anything with that, or if they are just relaying based on geography. We also don't know what the bandwidth to the ground stations is compared to the dishy. And remember that for every cell that a satellite takes over, it's also giving away one cell at the same time. I'm not saying that the problem is trivial, but just that it's not unique David Lang