From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp111.iad3a.emailsrvr.com (smtp111.iad3a.emailsrvr.com [173.203.187.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9344B3CB37 for ; Tue, 30 Aug 2022 12:53:53 -0400 (EDT) Received: from app52.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3B58451E8 for ; Tue, 30 Aug 2022 12:53:53 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app52.wa-webapps.iad3a (Postfix) with ESMTP id 231B3E1CB7; Tue, 30 Aug 2022 12:53:53 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 30 Aug 2022 12:53:53 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 30 Aug 2022 12:53:53 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net Cc: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220830125353000000_36687" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1661878433.14064713@apps.rackspace.com> X-Mailer: webmail/19.0.18-RC X-Classification-ID: e2c345b6-6e0e-493b-844c-cee2f7655668-1-1 Subject: [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: Tue, 30 Aug 2022 16:53:53 -0000 ------=_20220830125353000000_36687 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI have no clue why this matters (other than this is in color).=0A =0AThe= phased array antennas used by Starlink are quite limited - in particular, = there are 4 on each satellite and each earth-ground path is half-duplex, TD= M, essentially. Limited by hardware. The problem of signal equalization and= quantization limits prevent "space division multiplexing" and "frequency d= ivision multiplexing" in practice.=0A =0AThe 4 msec "turnaround time" at th= e physical level (satellite) means that time from a packet arriving at one = end to be sent to the other end of the sat-dishy links gets worse the more = dishys are served by one of the 4 antennas on the satellite. =0A=0Atrying t= o increase the coverage of an individual satellite basically means serving = more dishys per satellite, with less total bit rate, and much longer latenc= y due to the half duplexness.=0A =0ANow if the total bit rate of a sat-to-d= ishy link were, say, 1 Gigabit, like an 802.11ac AP gives you, and the turn= around time were under 1 microsecond rather than 4 msec. maybe then you co= uld get reasonable Internet service to dishys.=0A =0ABut 240 Mb/s or 172 Mb= /s as proposed for getting a bit more coverage per satellite? This is nowhe= re near competitive with what we expect in the US. =0A =0ASorry to rain on = all the techy dreaming.=0A =0AFirst, it's worth looking at all the problems= currently in WiFi performance when you share an AP with multiple active st= ations using 100's of Gb/s on the average (not just occasionally).=0A =0ADa= ve - you tried in "make-wifi-fast", and the architecture gets in the way th= ere. (yeah you can get point to point gigabit/sec single file transfers, bu= t to do that you invoke features that destroy latency and introduce huge va= riability if you share the AP at all, for these reasons).=0A =0AStarlink is= a good "last resort" service as constituted. But fiber and last few-hundre= d meters wireless is SO much better able to deliver good Internet service s= calably.=0AEven that assumes fixing the bufferbloat that the Starlink folks= don't seem to be able to address... ------=_20220830125353000000_36687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have no clue why thi= s matters (other than this is in color).

=0A

 <= /p>=0A

The phased array antennas used by Starlink are q= uite limited - in particular, there are 4 on each satellite and each earth-= ground path is half-duplex, TDM, essentially. Limited by hardware. The prob= lem of signal equalization and quantization limits prevent "space division = multiplexing" and "frequency division multiplexing" in practice.

=0A

 

=0A

The 4 msec "turnaround t= ime" at the physical level (satellite) means that time from a packet arrivi= ng at one end to be sent to the other end of the sat-dishy links gets worse= the more dishys are served by one of the 4 antennas on the satellite. = ;

trying to increase the coverage of an individual satellite bas= ically means serving more dishys per satellite, with less total bit rate, a= nd much longer latency due to the half duplexness.

=0A

 

=0A

Now if the total bit rate of a sat-to-= dishy link were, say, 1 Gigabit, like an 802.11ac AP gives you, and the tur= naround time were under 1 microsecond rather than 4 msec.  maybe then = you could get reasonable Internet service to dishys.

=0A

 

=0A

But 240 Mb/s or 172 Mb/s as proposed= for getting a bit more coverage per satellite? This is nowhere near compet= itive with what we expect in the US. 

=0A

 = ;

=0A

Sorry to rain on all the techy dreaming.

= =0A

 

=0A

First, it's worth= looking at all the problems currently in WiFi performance when you share a= n AP with multiple active stations using 100's of Gb/s on the average (not = just occasionally).

=0A

 

=0A

Dave - you tried in "make-wifi-fast", and the architecture gets in th= e way there. (yeah you can get point to point gigabit/sec single file trans= fers, but to do that you invoke features that destroy latency and introduce= huge variability if you share the AP at all, for these reasons).

=0A

 

=0A

Starlink is a good "las= t resort" service as constituted. But fiber and last few-hundred meters wir= eless is SO much better able to deliver good Internet service scalably.

= =0A

Even that assumes fixing the bufferbloat that the S= tarlink folks don't seem to be able to address...

 ------=_20220830125353000000_36687--