Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
* [Starlink] musk: 28ms median latency on starlink
@ 2024-06-02 17:13 Dave Taht
  2024-06-02 18:17 ` Sauli Kiviranta
                   ` (4 more replies)
  0 siblings, 5 replies; 13+ messages in thread
From: Dave Taht @ 2024-06-02 17:13 UTC (permalink / raw)
  To: Dave Taht via Starlink

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

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 Waves Podcast
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 2035 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-02 17:13 [Starlink] musk: 28ms median latency on starlink Dave Taht
@ 2024-06-02 18:17 ` Sauli Kiviranta
  2024-06-02 18:23   ` Oleg Kutkov
  2024-06-03 10:40 ` Ulrich Speidel
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 13+ messages in thread
From: Sauli Kiviranta @ 2024-06-02 18:17 UTC (permalink / raw)
  To: Dave Taht via Starlink


[-- Attachment #1.1: Type: text/plain, Size: 1634 bytes --]

Test 1:
https://www.waveform.com/tools/bufferbloat?test-id=95025c65-684f-4046-a84e-1a09e766b997
Screenshot 2024-06-02 at 20.28.09

Test 2:
https://www.waveform.com/tools/bufferbloat?test-id=0855024d-401c-4b5f-bc83-39d11b831e18
Screenshot 2024-06-02 at 20.30.42

Dishy page started to act wonky so could not run on this machine the native
test. Usually it shows pretty good numbers, maybe a bit optimistic some
times.

On Sun, Jun 2, 2024 at 8:13 PM Dave Taht via Starlink <
starlink@lists.bufferbloat.net> 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 Waves Podcast
> Dave Täht CSO, LibreQos
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #1.2: Type: text/html, Size: 3489 bytes --]

[-- Attachment #2: Screenshot 2024-06-02 at 20.28.09.png --]
[-- Type: image/png, Size: 227800 bytes --]

[-- Attachment #3: Screenshot 2024-06-02 at 20.30.42.png --]
[-- Type: image/png, Size: 354024 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-02 18:17 ` Sauli Kiviranta
@ 2024-06-02 18:23   ` Oleg Kutkov
  0 siblings, 0 replies; 13+ messages in thread
From: Oleg Kutkov @ 2024-06-02 18:23 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]

The Dishy page (192.168.100.1) has been broken for a long time. The 
backend gRPC API underwent many changes, but they don't have anyone to 
support the web interface, so it's virtually abandoned.

Native Starlink speed test is running on the Starlink router, not the Dishy.

On 6/2/24 21:17, Sauli Kiviranta via Starlink wrote:
> Test 1:
> https://www.waveform.com/tools/bufferbloat?test-id=95025c65-684f-4046-a84e-1a09e766b997
> Screenshot 2024-06-02 at 20.28.09
>
> Test 2:
> https://www.waveform.com/tools/bufferbloat?test-id=0855024d-401c-4b5f-bc83-39d11b831e18
> Screenshot 2024-06-02 at 20.30.42
>
> Dishy page started to act wonky so could not run on this machine the 
> native test. Usually it shows pretty good numbers, maybe a bit 
> optimistic some times.
>
> On Sun, Jun 2, 2024 at 8:13 PM Dave Taht via Starlink 
> <starlink@lists.bufferbloat.net> 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
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

-- 
Best regards,
Oleg Kutkov

[-- Attachment #2: Type: text/html, Size: 6212 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-02 17:13 [Starlink] musk: 28ms median latency on starlink Dave Taht
  2024-06-02 18:17 ` Sauli Kiviranta
@ 2024-06-03 10:40 ` Ulrich Speidel
  2024-06-03 16:43   ` David Lang
  2024-06-04  0:08 ` J Pan
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 13+ messages in thread
From: Ulrich Speidel @ 2024-06-03 10:40 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 3422 bytes --]

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

-- 
****************************************************************
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/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 6086 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-03 10:40 ` Ulrich Speidel
@ 2024-06-03 16:43   ` David Lang
  2024-06-03 17:41     ` Mike Puchol
  0 siblings, 1 reply; 13+ messages in thread
From: David Lang @ 2024-06-03 16:43 UTC (permalink / raw)
  To: Ulrich Speidel; +Cc: starlink

[-- 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-03 16:43   ` David Lang
@ 2024-06-03 17:41     ` Mike Puchol
  2024-06-03 21:59       ` Ulrich Speidel
  0 siblings, 1 reply; 13+ messages in thread
From: Mike Puchol @ 2024-06-03 17:41 UTC (permalink / raw)
  To: Ulrich Speidel, David Lang; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 4788 bytes --]

While the terminals use focused beams, Starlink does not operate in isolation or using protected spectrum. They must comply with EPFD limits, which are the reason why they just cannot land two co-frequency beams that overlap, as they could be causing harmful interference to other users of the same spectrum.

Best,

Mike
On Jun 3, 2024 at 09:43 -0700, David Lang via Starlink <starlink@lists.bufferbloat.net>, wrote:
> 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
> >
> >
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 5538 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-03 17:41     ` Mike Puchol
@ 2024-06-03 21:59       ` Ulrich Speidel
  0 siblings, 0 replies; 13+ messages in thread
From: Ulrich Speidel @ 2024-06-03 21:59 UTC (permalink / raw)
  To: Mike Puchol, David Lang; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 7403 bytes --]

On 4/06/2024 5:41 am, Mike Puchol wrote:
> While the terminals use focused beams, Starlink does not operate in 
> isolation or using protected spectrum. They must comply with EPFD 
> limits, which are the reason why they just cannot land two 
> co-frequency beams that overlap, as they could be causing harmful 
> interference to other users of the same spectrum.

Precisely.

Likewise, the famous "25 degrees over the horizon" isn't a nod to "too 
many trees/houses around Dishy", but there to satisfy the regulators 
that a transmitting beam from a satellite won't get into (more or less 
horizontally pointing) terrestrial communication systems (there's a 
softening of that requirement to 5 degrees minimum for beams to gateways 
at higher latitudes only).

It's also notable that this EPFD limit leads to a de-facto 
standardisation of the downlink as such. In a "textbook" system, you'd 
have some transmit power on the satellite, some antenna gain up there, 
you'd then take into account the path loss from spherical spreading of 
the signal on its way down, which gives you a PFD at your receiver site 
that depends on the geometry of the satellite-ground station 
arrangement. You'd then also look at your receive antenna gain. That's 
determined by the antenna aperture, which in the case of a phased array, 
is the collective area of all antenna elements. And since you're 
steering your receive beam, you'd be downrating the aperture by the 
cosine of your steering angle. And then you'd end up with some signal to 
noise ratio at the receiver which determines what modulation scheme you 
can use, and that along with the bandwidth of the link determines your 
capacity. But now you have a hard limit on your PFD imposed by the 
regulatory EPFD limit. So what SpaceX do according to their FCC filings 
is to reduce their EIRP at the satellite so the signal stays under/at 
the EPFD limit on the Earth's surface, and they adjust Dishy gain by 
using fewer of its elements the lower their steering angle is.

Put in another way:  If you could "see" Starlink satellite signals, they 
would appear equally bright to you no matter where in the sky they come 
from - you wouldn't be able to tell distance from brightness. Similarly, 
you could think of Dishy as a pair of sunglasses that are tinted most 
strongly in the middle but where the tinting fades as you look sideways. 
Sounds complex but results in SNR's that are a perfect fit for the 
modulation schemes (16QAM for Gen 1, 64QAM / 256QAM for Gen 2), so saves 
on satellite and Dishy having to negotiate modulation.

>
> Best,
>
> Mike
> On Jun 3, 2024 at 09:43 -0700, David Lang via Starlink 
> <starlink@lists.bufferbloat.net>, wrote:
>> 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
>>>
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

-- 
****************************************************************
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/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 11592 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-02 17:13 [Starlink] musk: 28ms median latency on starlink Dave Taht
  2024-06-02 18:17 ` Sauli Kiviranta
  2024-06-03 10:40 ` Ulrich Speidel
@ 2024-06-04  0:08 ` J Pan
  2024-06-04 14:53 ` Alexandre Petrescu
  2024-06-04 16:33 ` Livingood, Jason
  4 siblings, 0 replies; 13+ messages in thread
From: J Pan @ 2024-06-04  0:08 UTC (permalink / raw)
  To: Dave Taht; +Cc: Dave Taht via Starlink

it's better if elon can show the distribution of the ut-pop latency,
as median (or p50) does not tell anything about p99 as shown in
https://api.starlink.com/public-files/StarlinkLatency.pdf
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Sun, Jun 2, 2024 at 10:13 AM Dave Taht via Starlink
<starlink@lists.bufferbloat.net> 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 Waves Podcast
> Dave Täht CSO, LibreQos
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-02 17:13 [Starlink] musk: 28ms median latency on starlink Dave Taht
                   ` (2 preceding siblings ...)
  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
  4 siblings, 1 reply; 13+ messages in thread
From: Alexandre Petrescu @ 2024-06-04 14:53 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]


Le 02/06/2024 à 19:13, Dave Taht via Starlink a écrit :
> Via elon musk:
>
> Starlink just achieved a new internal median latency record of 28ms 
> yesterday! Great work by the engineering and operations teams.

It is indeed excellent news to hear that they achieve such a low 
latency.  It is worth noting.

In addition to fq_codel, cake and libreqos (acronyms I simply cite), if 
I may speculate how to further decrease the latency:

- lower the sat altitudes, maybe at 350km or even at 70km. These are 
altitudes where starlink sats seem parked at times, maybe right before 
reaching their stable 500km altitudes.  It means they can stay there, 
maybe for a shorter time than the times they stay at 500km, but still, 
for some time.

- make the antennas on the sats more 'wide-angle' so to speak, such as 
to make multiple spots on the ground, possible very distanced, rather 
than one single spot straight below the sat.

- add sat-to-HAP links. (high-alti platforms, i.e. 20km-to-70km), 
sat-to-plane, sat-to drone links (altitudes 500m-20km).

- add sat-to-other-constellations' sats links.

- have a dynamic IP routing system between sats and HAPS naturally 
finding shortest paths, i.e. lowest latencies.

I think one could target a 1ms latency.

Alex

>
> - 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/html, Size: 5011 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-02 17:13 [Starlink] musk: 28ms median latency on starlink Dave Taht
                   ` (3 preceding siblings ...)
  2024-06-04 14:53 ` Alexandre Petrescu
@ 2024-06-04 16:33 ` Livingood, Jason
  2024-06-04 18:34   ` J Pan
  2024-06-05 11:08   ` Alexandre Petrescu
  4 siblings, 2 replies; 13+ messages in thread
From: Livingood, Jason @ 2024-06-04 16:33 UTC (permalink / raw)
  To: Dave Taht, Dave Taht via Starlink

[-- Attachment #1: Type: text/plain, Size: 3239 bytes --]

First question is what was the test destination? From the CPE to a ground station or to something at a peering point or on the internet? I would assume either to ground station or 1 hop beyond (peering point)… That way we can do apples-to-apples comparisons, so to speak.

In any case, there is a lot of good 3rd party data out there for this. First is RIPE Atlas. I helped get a lot of probes deployed in the US and there are now 78 probes connected globally (roughly 30 would be sufficient to call it statistically significant): https://atlas.ripe.net/probes/public?sort=-id&toggle=all&page_size=100&search=AS14593&page=1&status=1. So if you know how to pull data from Atlas, it is there for you to analyze… (see https://atlas.ripe.net/docs/apis/rest-api-manual/ and https://atlas.ripe.net/docs/tools-and-code/latencymon.html

There is also this recent report that used a hardware probe connected over ethernet: https://www.netforecast.com/wp-content/uploads/FixedWireless_LEO_CableComparisonReport_NFR5148-1.pdf

Another approach similar to accessing RIPE Atlas data would be to get the Cloudflare AIM data from M-Lab – see https://www.measurementlab.net/blog/cloudflare-aimscoredata-announcement/. There was also a recent 3rd party report on that (see Figure 1): https://www.netforecast.com/wp-content/uploads/NFR5150_NetForecast-ISP-Performance-Report-2024.pdf.

Jason


From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Reply-To: Dave Taht <dave.taht@gmail.com>
Date: Sunday, June 2, 2024 at 13:13
To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Subject: [Starlink] musk: 28ms median latency on starlink

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<https://urldefense.com/v3/__https:/twitter.com/elonmusk/status/1797282250574184587__;!!CQl3mcHX2A!Fo8uFKdmFfKjawQrmiHSiyPIfMeLkSmEDbZ7r3K6SUa6razTwsaV2N4vFYYuMFizfHJf-oPpQLsMuW6fdCXIyWT4k75JoVsfRQ$>

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<https://urldefense.com/v3/__https:/www.waveform.com/tools/bufferbloat?test-id=2a1d139b-87cb-4ba4-a829-e2167801cffe__;!!CQl3mcHX2A!Fo8uFKdmFfKjawQrmiHSiyPIfMeLkSmEDbZ7r3K6SUa6razTwsaV2N4vFYYuMFizfHJf-oPpQLsMuW6fdCXIyWT4k75XAxHvIw$>

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://urldefense.com/v3/__https:/www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s__;!!CQl3mcHX2A!Fo8uFKdmFfKjawQrmiHSiyPIfMeLkSmEDbZ7r3K6SUa6razTwsaV2N4vFYYuMFizfHJf-oPpQLsMuW6fdCXIyWT4k760_tKaJA$> Waves Podcast
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 7999 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-04 14:53 ` Alexandre Petrescu
@ 2024-06-04 18:24   ` David Lang
  0 siblings, 0 replies; 13+ messages in thread
From: David Lang @ 2024-06-04 18:24 UTC (permalink / raw)
  To: Alexandre Petrescu; +Cc: starlink

[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]

On Tue, 4 Jun 2024, Alexandre Petrescu via Starlink wrote:

> Le 02/06/2024 à 19:13, Dave Taht via Starlink a écrit :
>> Via elon musk:
>> 
>> Starlink just achieved a new internal median latency record of 28ms 
>> yesterday! Great work by the engineering and operations teams.
>
> It is indeed excellent news to hear that they achieve such a low latency.  It 
> is worth noting.
>
> In addition to fq_codel, cake and libreqos (acronyms I simply cite), if I may 
> speculate how to further decrease the latency:
>
> - lower the sat altitudes, maybe at 350km or even at 70km. These are 
> altitudes where starlink sats seem parked at times, maybe right before 
> reaching their stable 500km altitudes.  It means they can stay there, maybe 
> for a shorter time than the times they stay at 500km, but still, for some 
> time.

they do have orbital shells scheduled for the 350km range

> - make the antennas on the sats more 'wide-angle' so to speak, such as to 
> make multiple spots on the ground, possible very distanced, rather than one 
> single spot straight below the sat.

we know that they have several antennas on each sat, and the V2 sats will have 
more (and probably bigger ones)

> - add sat-to-HAP links. (high-alti platforms, i.e. 20km-to-70km), 
> sat-to-plane, sat-to drone links (altitudes 500m-20km).

would those really be much different than the existing ground stations?

> - add sat-to-other-constellations' sats links.

well, there need to be other constellations to connect to first :-)

> - have a dynamic IP routing system between sats and HAPS naturally finding 
> shortest paths, i.e. lowest latencies.
>
> I think one could target a 1ms latency.

even down at 300Km, and assuming the satellite is directly overhead, that's 
~5ms round trip, and to avoid interference with higher satellites, they don't 
operate directly overhead, I think 10ms is more in the ballpark of theoretical 
maximum, and a goal of 20ms is aggressive.

David Lang

> Alex
>
>> 
>> - 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-04 16:33 ` Livingood, Jason
@ 2024-06-04 18:34   ` J Pan
  2024-06-05 11:08   ` Alexandre Petrescu
  1 sibling, 0 replies; 13+ messages in thread
From: J Pan @ 2024-06-04 18:34 UTC (permalink / raw)
  To: Livingood, Jason; +Cc: Dave Taht, Dave Taht via Starlink

it's the user dish (ut) to pop (or ip gateway more precisely, not the
ground station, collocated with the user's home pop) latency. thanks
for the ripe atlas probes---we are hosting and using them too---the
downside of ripe atlas is that it's mostly user hosted (so not always
online) and the space and time granularity of the measurements that
can be done for research
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Tue, Jun 4, 2024 at 9:33 AM Livingood, Jason via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> First question is what was the test destination? From the CPE to a ground station or to something at a peering point or on the internet? I would assume either to ground station or 1 hop beyond (peering point)… That way we can do apples-to-apples comparisons, so to speak.
>
>
>
> In any case, there is a lot of good 3rd party data out there for this. First is RIPE Atlas. I helped get a lot of probes deployed in the US and there are now 78 probes connected globally (roughly 30 would be sufficient to call it statistically significant): https://atlas.ripe.net/probes/public?sort=-id&toggle=all&page_size=100&search=AS14593&page=1&status=1. So if you know how to pull data from Atlas, it is there for you to analyze… (see https://atlas.ripe.net/docs/apis/rest-api-manual/ and https://atlas.ripe.net/docs/tools-and-code/latencymon.html
>
>
>
> There is also this recent report that used a hardware probe connected over ethernet: https://www.netforecast.com/wp-content/uploads/FixedWireless_LEO_CableComparisonReport_NFR5148-1.pdf
>
>
>
> Another approach similar to accessing RIPE Atlas data would be to get the Cloudflare AIM data from M-Lab – see https://www.measurementlab.net/blog/cloudflare-aimscoredata-announcement/. There was also a recent 3rd party report on that (see Figure 1): https://www.netforecast.com/wp-content/uploads/NFR5150_NetForecast-ISP-Performance-Report-2024.pdf.
>
>
>
> Jason
>
>
>
>
>
> From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: Dave Taht <dave.taht@gmail.com>
> Date: Sunday, June 2, 2024 at 13:13
> To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> Subject: [Starlink] musk: 28ms median latency on starlink
>
>
>
> 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 Waves Podcast
>
> Dave Täht CSO, LibreQos
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Starlink] musk: 28ms median latency on starlink
  2024-06-04 16:33 ` Livingood, Jason
  2024-06-04 18:34   ` J Pan
@ 2024-06-05 11:08   ` Alexandre Petrescu
  1 sibling, 0 replies; 13+ messages in thread
From: Alexandre Petrescu @ 2024-06-05 11:08 UTC (permalink / raw)
  To: starlink

[-- Attachment #1: Type: text/plain, Size: 4417 bytes --]


Le 04/06/2024 à 18:33, Livingood, Jason via Starlink a écrit :
>
> First question is what was the test destination? From the CPE to a 
> ground station or to something at a peering point or on the internet? 
> I would assume either to ground station or 1 hop beyond (peering 
> point)… That way we can do apples-to-apples comparisons, so to speak.
>
> In any case, there is a lot of good 3^rd party data out there for 
> this. First is RIPE Atlas. I helped get a lot of probes deployed in 
> the US and there are now 78 probes connected globally (roughly 30 
> would be sufficient to call it statistically significant): 
> https://atlas.ripe.net/probes/public?sort=-id&toggle=all&page_size=100&search=AS14593&page=1&status=1 
> <https://atlas.ripe.net/probes/public?sort=-id&toggle=all&page_size=100&search=AS14593&page=1&status=1>. 
> So if you know how to pull data from Atlas, it is there for you to 
> analyze… (see https://atlas.ripe.net/docs/apis/rest-api-manual/ and 
> https://atlas.ripe.net/docs/tools-and-code/latencymon.html
>
> There is also this recent report that used a hardware probe connected 
> over ethernet: 
> https://www.netforecast.com/wp-content/uploads/FixedWireless_LEO_CableComparisonReport_NFR5148-1.pdf
>
> Another approach similar to accessing RIPE Atlas data would be to get 
> the Cloudflare AIM data from M-Lab – see 
> https://www.measurementlab.net/blog/cloudflare-aimscoredata-announcement/. 
> There was also a recent 3^rd party report on that (see Figure 1): 
> https://www.netforecast.com/wp-content/uploads/NFR5150_NetForecast-ISP-Performance-Report-2024.pdf. 
>
>
I was having the same question of where are the test destinations when 
talking about 28ms latencies.

For my part, when I read latency evaluations expressed in milliseconds 
of RTT (round-trip time) I kind of assume we talk about using the tool 
of the website speedtest.net.  It is a very approximate number but I 
think it is understood by many people. That speedtest.net website has 
some server participants.  The test indicates where is situated the 
particular server in use.

Of course, ideally, spacex should tell precisely how they obtained that 
latency number (28ms), but I doubt they'll ever get into that kind of 
detail.  It's as if I asked them to tell what algorithm is behind xai, 
or so.

Alex

> Jason
>
> *From: *Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of 
> Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> *Reply-To: *Dave Taht <dave.taht@gmail.com>
> *Date: *Sunday, June 2, 2024 at 13:13
> *To: *Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> *Subject: *[Starlink] musk: 28ms median latency on starlink
>
> 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 
> <https://urldefense.com/v3/__https:/twitter.com/elonmusk/status/1797282250574184587__;!!CQl3mcHX2A!Fo8uFKdmFfKjawQrmiHSiyPIfMeLkSmEDbZ7r3K6SUa6razTwsaV2N4vFYYuMFizfHJf-oPpQLsMuW6fdCXIyWT4k75JoVsfRQ$>
>
> 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 
> <https://urldefense.com/v3/__https:/www.waveform.com/tools/bufferbloat?test-id=2a1d139b-87cb-4ba4-a829-e2167801cffe__;!!CQl3mcHX2A!Fo8uFKdmFfKjawQrmiHSiyPIfMeLkSmEDbZ7r3K6SUa6razTwsaV2N4vFYYuMFizfHJf-oPpQLsMuW6fdCXIyWT4k75XAxHvIw$>
>
> 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://urldefense.com/v3/__https:/www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s__;!!CQl3mcHX2A!Fo8uFKdmFfKjawQrmiHSiyPIfMeLkSmEDbZ7r3K6SUa6razTwsaV2N4vFYYuMFizfHJf-oPpQLsMuW6fdCXIyWT4k760_tKaJA$> 
> Waves Podcast
>
> Dave Täht CSO, LibreQos
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 11538 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2024-06-05 11:08 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-02 17:13 [Starlink] musk: 28ms median latency on starlink 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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox