From: Dave Taht <dave.taht@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] a puzzling starlink uplink trace
Date: Thu, 31 Aug 2023 06:36:30 -0700 [thread overview]
Message-ID: <CAA93jw4mDaNgZ8QDwxhaxafX66wRDwEVWxZQnGLh3-uSUEsYig@mail.gmail.com> (raw)
In-Reply-To: <c1fb2d22-aedf-68cd-3788-4ea14c1d5136@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4661 bytes --]
Zooming in on the anomalous behavior (attached, I also include the
flent.gz file for those of you that have the flent-gui installed,
which contains a timestamp for those of you plugged into orbit
calculation software), and plotting ping, tcp rtt and throughput, the
ping does indeed hit 20ms, but the tcp rtt only falls to 40ms. Could
they be synthesizing ping responses? I can think of a few ways to
detect that (putting some data in the payload, trying a different ping
type, like 13 (it tickled me that the sqm-autorate project discovered
that the ping timestamp option actually worked over some devices). Or
perhaps ping was taking a different sat entirely?
I like the idea of starlink finding some way to leverage satellites
moving into the right orbits. (the timestamp of this trace was
2023-08-27 06:59:35 UTC and I am in half moon bay, ca) This would
imply that they can transmit data at full thrust, and also, perhaps,
VLEO (I am not sure if that is an established acronym - very low earth
orbit operations) - feasible. Dropping the things even lower, making
the shell more aerodynamic, and burning fuel to stay there might well
be an interesting option. It seems to me the current altitude(s) are
pretty conservative and given the fuel consumption reported on the
maneuvering side, they can last at 530km much longer than 5 years, and
with the pace of technology and launch rates, moving them lower would
be a huge win for bandwidth and latency.
On Thu, Aug 31, 2023 at 2:13 AM Alexandre Petrescu via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> to clarify: I some times look with satmap.space and with n2yo.com at sat
> altitudes.
>
> Some times I see some starlink sats at lower altitudes than LEO (some
> times at 70km).
>
> Right now I see sat STARLINK-6065 at 360 km altitude, which is way below
> LEO and typical 550km altitude of starlink sats.
>
> https://www.n2yo.com/satellite/?s=56812
>
> If these altitude reports are correct, then I think it is hard to say
> Starlink is anymore simply a LEO constellation. It is much lower than that.
>
> Further, if the 20ms latency report is due to that 365 km altitude then
> it is very easy to imagine what lower altitudes would give.
>
> If one reports a great ms latency then it would be great to tell which
> sat at which altitude was there above at that timestamp.
>
> Alex
>
> Le 31/08/2023 à 10:56, Alexandre Petrescu via Starlink a écrit :
> >
> > Le 30/08/2023 à 20:07, Dave Taht via Starlink a écrit :
> >> In the attached 5 minute plot from a few days ago (I can supply the
> >> flent.gz files if anyone wants them), I see a puzzling spike at T+155s
> >> to nearly 90ms of baseline latency, then down to 20ms.
> >
> > 20ms?
> >
> > A latency of 20ms might come if these low altitude starlink sats (70km
> > or so) pass by there?
> >
> > Or maybe I dont see quite well these sat altitudes.
> >
> > Alex
> >
> >
> >> No degree of
> >> orbital mechanics can apply to this change, even factoring in an over
> >> the horizon connection, routing packets on the ground through LA to
> >> seattle, and back, or using a couple ISLs, can make this add up for
> >> me. A combination of all that, kind of does make sense.
> >>
> >> The trace otherwise shows the sawtooth pattern of a single tcp flow ,
> >> a loss (sometimes catastrophic) at every downward bandwidth change.
> >>
> >> An assumption I have long been making is the latency staircase effect
> >> (see T+170) forward is achieving the best encoding rate at the
> >> distance then seen, the distance growing and the encoding rate falling
> >> in distinct steps, with a fixed amount of buffering, until finally
> >> that sat starts falling out of range, and it choses another at T+240s.
> >>
> >> But jeeze, a 70ms baseline latency swing? What gives? I imagine
> >> somehow correlating this with a mpls enabled traceroute might begin to
> >> make some sense of it, correlated by orbital positions....
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
--
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
[-- Attachment #2: mystery_tcp_rtt_ping.png --]
[-- Type: image/png, Size: 368976 bytes --]
[-- Attachment #3: tcp_nup-2023-08-27T065935.741922.starlink-long-ipv4-1-flows.flent.gz --]
[-- Type: application/gzip, Size: 196415 bytes --]
next prev parent reply other threads:[~2023-08-31 13:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 18:07 Dave Taht
2023-08-30 19:43 ` Sebastian Moeller
2023-08-31 13:42 ` Dave Taht
2023-08-31 14:31 ` Sebastian Moeller
2023-08-31 8:56 ` Alexandre Petrescu
2023-08-31 9:13 ` Alexandre Petrescu
2023-08-31 11:43 ` David Lang
2023-08-31 13:36 ` Dave Taht [this message]
2023-08-31 13:54 ` David Lang
2023-09-15 11:17 ` 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=CAA93jw4mDaNgZ8QDwxhaxafX66wRDwEVWxZQnGLh3-uSUEsYig@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=alexandre.petrescu@gmail.com \
--cc=starlink@lists.bufferbloat.net \
/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