From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E1F3F3B29D for ; Fri, 13 Jan 2023 12:02:23 -0500 (EST) Received: by mail-vk1-xa2e.google.com with SMTP id t2so10479722vkk.9 for ; Fri, 13 Jan 2023 09:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackaday-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lqYM3PnZbBkwy6bOq5JAD83N0296/awLA8d+8CAL7aw=; b=ThSzGUUzSB3xMZYicV7Qg+eOqz2Jsf2rKpzSp+bVGQSG/BfRD4Ui7+2olqKwQMxxyF 5Jxg7wcnX6XzD+hiKGDWcLPseD5fwI4RI3288E+65fiaghUYn7u8Zw12u3LcsMt2q98a LvjNt9LuIPjuIdpBVbEpkYkK+9XGKP5NxA8fxKnmx7etaKfiWH8FPtQJyWlFR4Az1MEr C8x8D46UhbeGBEzbn2Pwn6i+u+kgXI3sfyXJgkUrinD1p/uBfy7jKV2ProNgCmojhp4F oCHqR6IQFXNi/noULKNfo8BSQHchZCGgkithsWhQ7rGuVQtYGtnyCQchT9bbQ8PEKzuU JdQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lqYM3PnZbBkwy6bOq5JAD83N0296/awLA8d+8CAL7aw=; b=agFTq+3h2e3Uc8UaF7Cs6OohWzfRhXJ2C0nhF5UkcIgQycDkuH0hTKYKN8Eg6G3rwl cUBPEN65spEKhZXHx7O82miiejP3NmDSANQ9HqsPJzjjApqdfWMiGtJIr10i2ma5HToL rREdXtDK6INPsxUWJay46kIzboYSevdWRnesgqT6GUdYsKeJRBJK+jKNM3lmVm18dCf2 BcNUp0V+K2jkAAnufr6dMKhSAzL/OLpLVbAELU5U3SmDUppka68l3LGB70MzVO/B8VfB Om1j+dhMMUauPtCEYfF3x6QuJ23f7I36vugaa1KiNapoDO0VzW3P17JPZUAGC/5qNORX V+Rg== X-Gm-Message-State: AFqh2krtWGBiXCBnCzMTw3BUEP0B/6l3s6v2N92Mit4lDF+N/jr96Iky jXQAysd2LnXE33R2+JEwYYMRhsqFfMTbxxsg1ad6zWTX/zntPQ== X-Google-Smtp-Source: AMrXdXsLs67TTXIrnaCbHENHeqI3N8JxyLKLONHu6utyB+4oKja5SWgJrcQTCkLffHdRI4RpVdkmMRhxMSH1ouWC7VM= X-Received: by 2002:a1f:b294:0:b0:3d5:d2a3:8c22 with SMTP id b142-20020a1fb294000000b003d5d2a38c22mr6150601vkf.39.1673629343177; Fri, 13 Jan 2023 09:02:23 -0800 (PST) MIME-Version: 1.0 References: <89D796E75967416B9723211C183A8396@SRA6> <3696AEA5409D4303ABCBC439727A5E40@SRA6> In-Reply-To: From: Jonathan Bennett Date: Fri, 13 Jan 2023 11:02:12 -0600 Message-ID: To: Ulrich Speidel Cc: starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000007c7c2005f228329f" Subject: Re: [Starlink] insanely great waveform result for starlink X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2023 17:02:24 -0000 --0000000000007c7c2005f228329f Content-Type: text/plain; charset="UTF-8" On Fri, Jan 13, 2023 at 6:28 AM Ulrich Speidel via Starlink < starlink@lists.bufferbloat.net> wrote: > On 13/01/2023 6:13 pm, Ulrich Speidel wrote: > > > > From Auckland, New Zealand, using a roaming subscription, it puts me > > in touch with a server 2000 km away. OK then: > > > > > > IP address: nix six. > > > > My thoughts shall follow later. > > OK, so here we go. > > I'm always a bit skeptical when it comes to speed tests - they're really > laden with so many caveats that it's not funny. I took our new work > Starlink kit home in December to give it a try and the other day finally > got around to set it up. It's on a roaming subscription because our > badly built-up campus really isn't ideal in terms of a clear view of the > sky. Oh - and did I mention that I used the Starlink Ethernet adapter, > not the WiFi? > > Caveat 1: Location, location. I live in a place where the best Starlink > promises is about 1/3 in terms of data rate you can actually get from > fibre to the home at under half of Starlink's price. Read: There are few > Starlink users around. I might be the only one in my suburb. > > Caveat 2: Auckland has three Starlink gateways close by: Clevedon (which > is at a stretch daytrip cycling distance from here), Te Hana and Puwera, > the most distant of the three and about 130 km away from me as the crow > flies. Read: My dishy can use any satellite that any of these three can > see, and then depending on where I put it and how much of the southern > sky it can see, maybe also the one in Hinds, 840 km away, although that > is obviously stretching it a bit. Either way, that's plenty of options > for my bits to travel without needing a lot of handovers. Why? Easy: If > your nearest teleport is close by, then the set of satellites that the > teleport can see and the set that you can see is almost the same, so you > can essentially stick with the same satellite while it's in view for you > because it'll also be in view for the teleport. Pretty much any bird > above you will do. > > And because I don't get a lot of competition from other users in my area > vying for one of the few available satellites that can see both us and > the teleport, this is about as good as it gets at 37S latitude. If I'd > want it any better, I'd have to move a lot further south. > > It'd be interesting to hear from Jonathan what the availability of home > broadband is like in the Dallas area. I note that it's at a lower > latitude (33N) than Auckland, but the difference isn't huge. I notice > two teleports each about 160 km away, which is also not too bad. I also > note Starlink availability in the area is restricted at the moment - > oversubscribed? But if Jonathan gets good data rates, then that means > that competition for bird capacity can't be too bad - for whatever reason. > I'm in Southwest Oklahoma, but Dallas is the nearby Starlink gateway. In cities, like Dallas, and Lawton where I live, there are good broadband options. But there are also many people that live outside cities, and the options are much worse. The low density userbase in rural Oklahoma and Texas is probably ideal conditions for Starlink. > > Caveat 3: Backhaul. There isn't just one queue between me and whatever I > talk to in terms of my communications. Traceroute shows about 10 hops > between me and the University of Auckland via Starlink. That's 10 > queues, not one. Many of them will have cross traffic. So it's a bit > hard to tell where our packets really get to wait or where they get > dropped. The insidious bit here is that a lot of them will be between 1 > Gb/s and 10 Gb/s links, and with a bit of cross traffic, they can all > turn into bottlenecks. This isn't like a narrowband GEO link of a few > Mb/s where it's obvious where the dominant long latency bottleneck in > your TCP connection's path is. Read: It's pretty hard to tell whether a > drop in "speed" is due to a performance issue in the Starlink system or > somewhere between Starlink's systems and the target system. > > I see RTTs here between 20 ms and 250 ms, where the physical latency > should be under 15 ms. So there's clearly a bit of buffer here along the > chain that occasionally fills up. > > Caveat 4: Handovers. Handover between birds and teleports is inevitably > associated with a change in RTT and in most cases also available > bandwidth. Plus your packets now arrive at a new queue on a new > satellite while your TCP is still trying to respond to whatever it > thought the queue on the previous bird was doing. Read: Whatever your > cwnd is immediately after a handover, it's probably not what it should be. > > I ran a somewhat hamstrung (sky view restricted) set of four Ookla > speedtest.net tests each to five local servers. Average upload rate was > 13 Mb/s, average down 75.5 Mb/s. Upload to the server of the ISP that > Starlink seems to be buying its local connectivity from (Vocus Group) > varied between 3.04 and 14.38 Mb/s, download between 23.33 and 52.22 > Mb/s, with RTTs between 37 and 56 ms not correlating well to rates > observed. In fact, they were the ISP with consistently the worst rates. > > Another ISP (MyRepublic) scored between 11.81 and 21.81 Mb/s up and > between 106.5 and 183.8 Mb/s down, again with RTTs badly correlating > with rates. Average RTT was the same as for Vocus. > > Note the variation though: More or less a factor of two between highest > and lowest rates for each ISP. Did MyRepublic just get lucky in my > tests? Or is there something systematic behind this? Way too few tests > to tell. > > What these tests do is establish a ballpark. > > I'm currently repeating tests with dish placed on a trestle closer to > the heavens. This seems to have translated into fewer outages / ping > losses (around 1/4 of what I had yesterday with dishy on the ground on > my deck). Still good enough for a lengthy video Skype call with my folks > in Germany, although they did comment about reduced video quality. But > maybe that was the lighting or the different background as I wasn't in > my usual spot with my laptop when I called them. > Clear view of the sky is king for Starlink reliability. I've got my dishy mounted on the back fence, looking up over an empty field, so it's pretty much best-case scenario here. > > -- > > **************************************************************** > 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 > --0000000000007c7c2005f228329f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jan 13, 2023 at 6:28 AM U= lrich Speidel via Starlink <starlink@lists.bufferbloat.net> wrote:
On 13/01/2023 6:13 pm, Ulrich Speidel w= rote:
>
> From Auckland, New Zealand, using a roaming subscription, it puts me <= br> > in touch with a server 2000 km away. OK then:
>
>
> IP address: nix six.
>
> My thoughts shall follow later.

OK, so here we go.

I'm always a bit skeptical when it comes to speed tests - they're r= eally
laden with so many caveats that it's not funny. I took our new work Starlink kit home in December to give it a try and the other day finally got around to set it up. It's on a roaming subscription because our badly built-up campus really isn't ideal in terms of a clear view of th= e
sky. Oh - and did I mention that I used the Starlink Ethernet adapter,
not the WiFi?

Caveat 1: Location, location. I live in a place where the best Starlink promises is about 1/3 in terms of data rate you can actually get from
fibre to the home at under half of Starlink's price. Read: There are fe= w
Starlink users around. I might be the only one in my suburb.

Caveat 2: Auckland has three Starlink gateways close by: Clevedon (which is at a stretch daytrip cycling distance from here), Te Hana and Puwera, the most distant of the three and about 130 km away from me as the crow flies. Read: My dishy can use any satellite that any of these three can see, and then depending on where I put it and how much of the southern
sky it can see, maybe also the one in Hinds, 840 km away, although that is obviously stretching it a bit. Either way, that's plenty of options =
for my bits to travel without needing a lot of handovers. Why? Easy: If your nearest teleport is close by, then the set of satellites that the
teleport can see and the set that you can see is almost the same, so you can essentially stick with the same satellite while it's in view for yo= u
because it'll also be in view for the teleport. Pretty much any bird above you will do.

And because I don't get a lot of competition from other users in my are= a
vying for one of the few available satellites that can see both us and
the teleport, this is about as good as it gets at 37S latitude. If I'd =
want it any better, I'd have to move a lot further south.

It'd be interesting to hear from Jonathan what the availability of home=
broadband is like in the Dallas area. I note that it's at a lower
latitude (33N) than Auckland, but the difference isn't huge. I notice <= br> two teleports each about 160 km away, which is also not too bad. I also note Starlink availability in the area is restricted at the moment -
oversubscribed? But if Jonathan gets good data rates, then that means
that competition for bird capacity can't be too bad - for whatever reas= on.
I'm in Southwest Oklahoma, but Dallas is the n= earby Starlink gateway. In cities, like Dallas, and Lawton where I live, th= ere are good broadband options. But there are also many people that live ou= tside cities, and the options are much worse. The low density userbase in r= ural Oklahoma and Texas is probably ideal conditions for Starlink.

Caveat 3: Backhaul. There isn't just one queue between me and whatever = I
talk to in terms of my communications. Traceroute shows about 10 hops
between me and the University of Auckland via Starlink. That's 10
queues, not one. Many of them will have cross traffic. So it's a bit hard to tell where our packets really get to wait or where they get
dropped. The insidious bit here is that a lot of them will be between 1 Gb/s and 10 Gb/s links, and with a bit of cross traffic, they can all
turn into bottlenecks. This isn't like a narrowband GEO link of a few <= br> Mb/s where it's obvious where the dominant long latency bottleneck in <= br> your TCP connection's path is. Read: It's pretty hard to tell wheth= er a
drop in "speed" is due to a performance issue in the Starlink sys= tem or
somewhere between Starlink's systems and the target system.

I see RTTs here between 20 ms and 250 ms, where the physical latency
should be under 15 ms. So there's clearly a bit of buffer here along th= e
chain that occasionally fills up.

Caveat 4: Handovers. Handover between birds and teleports is inevitably associated with a change in RTT and in most cases also available
bandwidth. Plus your packets now arrive at a new queue on a new
satellite while your TCP is still trying to respond to whatever it
thought the queue on the previous bird was doing. Read: Whatever your
cwnd is immediately after a handover, it's probably not what it should = be.

I ran a somewhat hamstrung (sky view restricted) set of four Ookla
speed= test.net tests each to five local servers. Average upload rate was
13 Mb/s, average down 75.5 Mb/s. Upload to the server of the ISP that
Starlink seems to be buying its local connectivity from (Vocus Group)
varied between 3.04 and 14.38 Mb/s, download between 23.33 and 52.22
Mb/s, with RTTs between 37 and 56 ms not correlating well to rates
observed. In fact, they were the ISP with consistently the worst rates.

Another ISP (MyRepublic) scored between 11.81 and 21.81 Mb/s up and
between 106.5 and 183.8 Mb/s down, again with RTTs badly correlating
with rates. Average RTT was the same as for Vocus.

Note the variation though: More or less a factor of two between highest and lowest rates for each ISP. Did MyRepublic just get lucky in my
tests? Or is there something systematic behind this? Way too few tests
to tell.

What these tests do is establish a ballpark.

I'm currently repeating tests with dish placed on a trestle closer to <= br> the heavens. This seems to have translated into fewer outages / ping
losses (around 1/4 of what I had yesterday with dishy on the ground on
my deck). Still good enough for a lengthy video Skype call with my folks in Germany, although they did comment about reduced video quality. But
maybe that was the lighting or the different background as I wasn't in =
my usual spot with my laptop when I called them.
Clear= view of the sky is king for Starlink reliability. I've got my dishy mo= unted on the back fence, looking up over an empty field, so it's pretty= much best-case scenario here.=C2=A0

--

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

School of Computer Science

Room 303S.594 (City Campus)

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



_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--0000000000007c7c2005f228329f--