Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Colin_Higbie <CHigbie1@Higbie.name>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Ka vs Ku Band, Signal Angle, and Weather Impact
Date: Sun, 24 Nov 2024 17:59:11 +0000	[thread overview]
Message-ID: <MN2PR16MB3391719E28FE9ADF11541D38F12D2@MN2PR16MB3391.namprd16.prod.outlook.com> (raw)
In-Reply-To: <mailman.3.1732467601.30327.starlink@lists.bufferbloat.net>

Ulrich,

I know we see significant rain fade with geostationary satellites, which I have long assumed is at least in part because from our latitude (around 44 degrees north), the angle to a geostationary satellite is so small that it's going nearly horizontally through hundreds of miles of clouds. In contrast, Starlink satellites, nearly overhead, punch almost vertically straight through the clouds. This means it has far fewer water droplets and clouds to pass through to reach a satellite in the same weather. I assume this is at least partially responsible for why Starlink is VASTLY more reliable at holding a connection in bad weather than geostationary links. 

First, is that correct?

Second, does this have any bearing on your point about Ka not being good in the rain? I.e., maybe it's not as good in the rain as Ku, but because of the angle of communication and therefore reduced signal attenuation, it can still get through typical cloud cover and moderate rain, still "good enough"?

While obviously none of us want to lose connectivity or signal in the rain, I'd rather drop to some fractional capacity (whatever fits on Ku) during occasional bad storms, if it meant that the rest of the time, I could have much more bandwidth with added Ka support. But I acknowledge that I don't know how all these factors interact for final results.

Thanks for any info/education on this,
Colin


Date: Sun, 24 Nov 2024 16:39:28 +1300
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: Dave Taht <dave.taht@gmail.com>, Michael Richardson
	<mcr+ietf@sandelman.ca>
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink Internet Speeds Could Skyrocket to 2
	Gigabits Per Second, SpaceX President Says
Message-ID: <78ba68e7-11a7-4355-9264-b7ff16afab84@auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 24/11/2024 9:05 am, Dave Taht wrote:
>> 3. Elon will own the FCC.
> This FCC promises to open up more spectrum. Where?

I think it's not so much a matter of opening up spectrum. SpaceX's 
spectrum "reserve" at the moment is Ka-band. That's hitherto been used 
for gateways only, but with the lasers, that's becoming less of a 
bottleneck because you can in principle uplink from and downlink to a 
remote gateway or set of remote gateways (unlike with the end user - I 
mean Elon can't simply provide the service Dave's paying for over, say, 
New York, rather than where Dave's boat is). So that frees up a bit of 
resource to deploy directly to users in tight spots. Except that Dishy 
doesn't talk on Ka.

The trouble with Ka is that it's a bit more susceptible to rain fade 
than Ku, and also that the amount of spectrum available there isn't 
exactly an order of magnitude larger either. To the contrary - the three 
Ka-bands in which SpaceX can downlink data have a combined 1.8 GHz of 
spectrum - less than for Ku. The pros of Ka are that the shorter 
wavelength makes for sharper beams and a nicer link budget with the same 
size antennas. As long as you don't get rained on. So you better throw 
in some extra antenna gain, which is what they're doing with the 1.85 m 
dishes (not Dishys) at their community gateways. But that's an entirely 
different business model.

And yes I'm aware that there's some labelling issues as to what counts 
as Ka and what doesn't, internationally, and that the FCC's notion of Ka 
starts at lower frequencies than some other peoples'.

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************


       reply	other threads:[~2024-11-24 17:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.3.1732467601.30327.starlink@lists.bufferbloat.net>
2024-11-24 17:59 ` Colin_Higbie [this message]
2024-11-25  1:55   ` Ulrich Speidel
2024-11-26 16:29   ` Michael Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR16MB3391719E28FE9ADF11541D38F12D2@MN2PR16MB3391.namprd16.prod.outlook.com \
    --to=chigbie1@higbie.name \
    --cc=starlink@lists.bufferbloat.net \
    --cc=u.speidel@auckland.ac.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox