Based on the spacing on the sat bus, it’s likely there’s 3x TX antennas and
1x RX on the satellite.

On Tue, Aug 30, 2022 at 5:30 PM David P. Reed via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Hi Sascha -
>
> On Tuesday, August 30, 2022 6:39pm, starlink-request@lists.bufferbloat.net
> said:
> > Date: Tue, 30 Aug 2022 08:37:24 -0400
>
> > From: Sascha Meinrath <sascha@thexlab.org>
> > To: Dave Taht <dave.taht@gmail.com>, Dave Taht via Starlink
> > <starlink@lists.bufferbloat.net>
> > Subject:
> >
> > I'd be curious how accurate these simulations are -- even within
> something as
> > simple as LAN Wi-Fi, the "simulations" often are wildly/hyperbolically
> > over-stated. I could imagine that even a few over-rosy assumptions would
> > exponentially metastasize optimism within the satellite context.
>
>
>
> Very good point. They don't seem to be based on very thoughtful
> assumptions about the PHY level.
>
> Remember, each satellite has  4 phased array antenna that can each "focus"
> in one direction. That's a pretty severe limit. Those antennas can either
> transmit or receive. They can't do both at the same time. Multiple dishys
> probably will need to share the capacity of those 4 antennas on the uplink
> from dishy to satellite. They also share the capacity on the downlink
> (because the beaming tracks individual dishys.
>
>
>
> How are they "time shared"? Well you have two problems here - one is that
> you constantly drop dishys and pick up new ones as the satellite moves, so
> the "time division schedule" of each antenna has to be dynamic, especially
> as density of active dishys varies (and inactive ones might become active
> any millisecond or less - new packets being sent).
>
> Now it takes at least 4 milliseconds for the a new uplink slot to be
> acquired. That's the dishy->sat->dishy round trip at the speed of light.
> Multiple dishys per satellite antenna means that the uplink, and downlink
> traffic rates depend on how predictable the traffic is.
>
>
>
> Internet traffic (unlike classic voice or video which can be seen as a
> constant bit rate channel with long silence periods) is bursty at all
> timescales. It's fractally bursty, as studies have shown.
>
>
>
> Nothing of this sort is even modeled in this work.
>
>
>
> Now I first started working with 2 way satellite technology back in the
> Iridium days, and also with 2-way geosynchronous satellites that used RF
> transponders that just translated the frequency of the uplink to the
> downlink frequency and vice versa. (Tachyon was the company, I was working
> on some technology for Nicholas Negroponte's 2B1 project that decided on
> Tachyon and not Iridium for all kinds of reasons).
>
>
>
> The big problem in a multiplexed two way system (even at LEO) is that the
> satellite uplink traffic from one of the many terminals had to share one or
> a few channels (frequencies) and they can't hear each other. So Internet
> traffic has to be held until it can get a free time slot, or else the
> frequencies have to be divided among the terminals dynamically.
>
>
>
> This is the real issue with Starlink as load increases. And yet most
> people are pretending this scheduling problem doesn't exist!
>
>
>
> Even Dave Taht and his buddies who have worked on trying to solve the
> problem of sharing with 802.11 haven't made much progress in dealing with
> bursty traffic sharing with heavy load.
>
>
>
> And yet people are modeling as if this didn't even matter!  (well, it's
> not something that has arisen much in the classic one-way or
> non-multiplexed satellite systems. I don't think even commercial airline
> satellite systems try to share capacity among multiple planes dynamically.)
>
>
>
> The phased array tracking of satellites is indeed magical, and the ability
> to (in principle) switch directions between every 6 bit symbol time is very
> nice for the downlink from the satellite to multiple dishys.
>
> Great technology.
>
>
>
> But the multiplexing at the packet level given the burstiness of load and
> the need to stay under 20 msec. packet latency from dishy to anywhere in
> the continent is a problem. That's gonna destroy all interactive services
> as load grows. And that on top of bufferbloat (queueing delay under load
> caused by not dropping packets) that is apparently a problem in the system.
> and not being addressed.
>
>
>
> My response to these kind of studies is "measure based on reality" before
> you imagine what a good model is.
>
>
>
> >
> > --Sascha
> >
> > On 8/30/22 07:52, Dave Taht via Starlink wrote:
> > > mike is doing some great visualizations here:
> > >
> > > https://twitter.com/mikepuchol/status/1564544963857326081
> >
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>