From: David Lang <david@lang.hm>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] musk: 28ms median latency on starlink
Date: Mon, 3 Jun 2024 09:43:18 -0700 (PDT) [thread overview]
Message-ID: <431q71ps-pp33-92q1-824o-16p148q5pp1o@ynat.uz> (raw)
In-Reply-To: <00d881ed-682e-4ab9-8cad-ba5aea318251@auckland.ac.nz>
[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]
If the ground stations were omnidirectional antennas, you would be correct, but
since they are phased array directional antennas, they can steer the beam to
receive one satellite even while a different one is transmitting on the same
frequency to the same cell.
David Lang
On Mon, 3 Jun 2024, Ulrich Speidel via Starlink wrote:
> Date: Mon, 3 Jun 2024 22:40:24 +1200
> From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: Ulrich Speidel <u.speidel@auckland.ac.nz>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] musk: 28ms median latency on starlink
>
> Getting the satellite density up will help, but it will only improve things
> so far.
>
> The problem on user downlink in particular is that there's a limit on the
> maximum spectral power flux density that arrives from the satellite in space
> on the ground. If you point all (mutually compatible) user downlink beams
> from a single satellite at a single cell, you all but reach that limit there.
> In fact, where SpaceX want to use two beams on the same frequency but with
> opposite polarisations to the same cell, they must reduce the transmit power
> on each beam by 3 dB (50%) in order to stay within the limit. More satellites
> would give you more beams, but you can't point them at cells that already
> have a beam on the same frequency in use from another satellite (unless you
> de-rate on the power front, I guess). That seriously limits what you can
> receive in terms of total capacity within a single cell to what a single
> satellite's mutually compatible beams can deliver, which appears to be about
> 12 Gb/s on V1 and V1.5 birds, and 20 Gb/s on V2 (on Ku, if you add in Ka-band
> and anticipate Dishys that can do Ka, then it's a lot more for Ka). In
> practice, we know that a cell gets served by beams from different satellites,
> but the overall constraint still applies - if you deploy beam X from sat A
> and beam Y from sat B to the same cell, this makes the same contribution to
> PFD as deploying both from the same satellite. Note that Starlink sats do
> have multiple mutually incompatible beams that they can only point at
> different cells, bringing Ku user downlink capacity up to 16 Gb/s on V1 and
> 1.5, and 48 Gb/s on V2. But that only ups your chances of getting a larger
> slice of those 12 or 20 Gb/s in your cell.
>
> Your best bet for continuing good service at the moment is literally to tell
> your neighbours that Starlink is useless, so they don't sign up and you can
> have your cake all to yourself ;-)
>
> On 3/06/2024 5:13 am, Dave Taht via Starlink wrote:
>> Via elon musk:
>>
>> Starlink just achieved a new internal median latency record of 28ms
>> yesterday! Great work by the engineering and operations teams.
>>
>> - https://twitter.com/elonmusk/status/1797282250574184587
>>
>> I of course, am very interested in y'all´s external measurements of how
>> well starlink is doing. For me, it is fantastic - 30Mbit uploads nowadays,
>> 0
>> latency on the upload (how?)
>> https://www.waveform.com/tools/bufferbloat?test-id=2a1d139b-87cb-4ba4-a829-e2167801cffe
>>
>> I also keep hoping that the rest of the ISP industry is now paying
>> attention and deploying stuff like fq_codel and cake and libreqos, but, ah
>> well - I will settle for starlink blowing past a lot of dsl and cable and
>> finding ways to get their density up.
>>
>> Anyone going to the Starship launch on the 6th?
>>
>>
>>
>> --
>> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s
>> <https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s> Waves Podcast
>> Dave Täht CSO, LibreQos
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
next prev parent reply other threads:[~2024-06-03 16:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-02 17:13 Dave Taht
2024-06-02 18:17 ` Sauli Kiviranta
2024-06-02 18:23 ` Oleg Kutkov
2024-06-03 10:40 ` Ulrich Speidel
2024-06-03 16:43 ` David Lang [this message]
2024-06-03 17:41 ` Mike Puchol
2024-06-03 21:59 ` Ulrich Speidel
2024-06-04 0:08 ` J Pan
2024-06-04 14:53 ` Alexandre Petrescu
2024-06-04 18:24 ` David Lang
2024-06-04 16:33 ` Livingood, Jason
2024-06-04 18:34 ` J Pan
2024-06-05 11:08 ` Alexandre Petrescu
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=431q71ps-pp33-92q1-824o-16p148q5pp1o@ynat.uz \
--to=david@lang.hm \
--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