From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] First tests of the Starlink REV4 (aka gen3)
Date: Thu, 22 Feb 2024 13:18:50 +0100 [thread overview]
Message-ID: <c1d79f9c-75ee-402b-843b-135c0ac5ed90@gmail.com> (raw)
In-Reply-To: <4e7a1b3a-db75-4558-a5aa-42638ffa6962@auckland.ac.nz>
Le 25/01/2024 à 02:54, Ulrich Speidel via Starlink a écrit :
> On 25/01/2024 1:37 am, Alexandre Petrescu via Starlink wrote:
>> Thanks for the tests!
>>
>> The dl/ul speeds 300/15 mbit/s are impressive.
>
> "Speeds" (observed data rates) in terms of Starlink hardware are
> actually fairly meaningless as they depend on:
>
> * Satellite(s) involved in the data transfer over the duration of the
> measurement(s).
> * Load on those satellites, which depends on the number of other
> current users whose traffic goes via those birds, and what these
> users are up to. Note this changes between handovers.
> * RTT to other end of transfer path.
> * Packet loss (including beyond Starlink's network)
>
> Unless a Dishy is able to handle communication via multiple satellites
> in parallel, I would expect the rates to be the same more or less
> regardless of model used. In fact, I would expect a Dishy model that is
> able to align itself to do marginally better over time.
>
>>
>> At video pointer 5:53 the reported Ping ?/dl/ul 88/204/121 ms and Jitter
>> 9.2 ms seem interesting.
>>
>> ==> I am not sure which of the two (ping or jitter) you name
>> 'latency'?
> All of them I guess.
>>
>> ==> I am not sure why the dl (download) ping ms is higher than the ul.
> Because that is where you have the longer queues.
>>
>> ==> I don't know what is the first ('?') parameter reported as 88ms
>> for Ping?
>
> I presume unloaded ping RTT. The second is ping RTT during the download
> test (with inbound queues loaded), the last is ping RTT during the
> upload test (with outbound queues loaded).
>
> I'd also note here that these are values obtained from Kyiv, which isn't
> a Starlink environment that is easy to assess. For one, we don't know
> whether there are Starlink gateways in Ukraine, or if there are, where
> they'd be.
One could find 'Kyiv' in the list shown by
https://geoip.starlinkisp.net/feed.csv
(not sure whether that is a teleport or a point of presence without
satcom access).
Alex
We don't know where else there may be gateways - not
> every jurisdiction publishes this - or whether Starlink may even be
> operating opportunistic fair weather optical gateways which they don't
> have to disclose to anyone. Plus we don't know what may be carted into
> the area or away from it via laser links to gateways much further away.
>
>>
>> I wonder whether the DHCPv6-PD is still supported by REV4 and whether
>> the allocated prefix is still a non-/64 (i.e. a /56 delivered by
>> DHCPv6-PD reported earlier on this email list by Steven on Dec. 12, 2023)?
>>
>> Alex
>>
>> Le 23/01/2024 à 10:07, Oleg Kutkov via Starlink a écrit :
>> > I conducted the initial comparative tests of the new terminal in
>> > Ukraine. I guess it's not a really "legal" because the new terminal is
>> > not certified and not selling outside the US for the moment. But who
>> > cares.
>> >
>> > Here's a video: https://youtu.be/hWPMpJrjd1g
>> <https://youtu.be/hWPMpJrjd1g>
>> >
>> > I will try to do more technical tests next week. There will be a new
>> > video.
>> >
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>> <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/
> ****************************************************************
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
prev parent reply other threads:[~2024-02-22 12:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 9:07 Oleg Kutkov
2024-01-24 12:37 ` Alexandre Petrescu
2024-01-24 22:47 ` Oleg Kutkov
2024-01-24 23:40 ` Jonathan Bennett
2024-01-24 23:50 ` Oleg Kutkov
2024-01-25 1:29 ` David Lang
2024-01-25 1:54 ` Ulrich Speidel
2024-02-22 12:18 ` Alexandre Petrescu [this message]
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=c1d79f9c-75ee-402b-843b-135c0ac5ed90@gmail.com \
--to=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