Re: [Starlink] insanely great waveform result for starlink

[Nathan Owens <nathan@nathan.io>]

[-- Attachment #1.1.1: Type: text/plain, Size: 10110 bytes --]

Here's the data visualization for Johnathan's Data

[image: Screenshot 2023-01-13 at 12.29.15 PM.png]

You can see the path change at :12, :27, :42, :57 after the minute. Some
paths are clearly busier than others with increased loss, latency, and
jitter.

On Fri, Jan 13, 2023 at 10:09 AM Nathan Owens <nathan@nathan.io> wrote:

> I’ll run my visualization code on this result this afternoon and report
> back!
>
> On Fri, Jan 13, 2023 at 9:41 AM Jonathan Bennett via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> The irtt command, run with normal, light usage:
>> https://drive.google.com/file/d/1SiVCiUYnx7nDTxIVOY5w-z20S2O059rA/view?usp=share_link
>>
>> Jonathan Bennett
>> Hackaday.com
>>
>>
>> On Fri, Jan 13, 2023 at 11:26 AM Dave Taht <dave.taht@gmail.com> wrote:
>>
>>> packet caps would be nice... all this is very exciting news.
>>>
>>> I'd so love for one or more of y'all reporting such great uplink
>>> results nowadays to duplicate and re-plot the original irtt tests we
>>> did:
>>>
>>> irtt client -i3ms -d300s myclosestservertoyou.starlink.taht.net -o
>>> whatever.json
>>>
>>> They MUST have changed their scheduling to get such amazing uplink
>>> results, in addition to better queue management.
>>>
>>> (for the record, my servers are de, london, fremont, sydney, dallas,
>>> newark, atlanta, singapore, mumbai)
>>>
>>> There's an R and gnuplot script for plotting that output around here
>>> somewhere (I have largely personally put down the starlink project,
>>> loaning out mine) - that went by on this list... I should have written
>>> a blog entry so I can find that stuff again.
>>>
>>> On Fri, Jan 13, 2023 at 9:02 AM Jonathan Bennett via Starlink
>>> <starlink@lists.bufferbloat.net> wrote:
>>> >
>>> >
>>> > 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
>>> >
>>> > _______________________________________________
>>> > Starlink mailing list
>>> > Starlink@lists.bufferbloat.net
>>> > https://lists.bufferbloat.net/listinfo/starlink
>>>
>>>
>>>
>>> --
>>> This song goes out to all the folk that thought Stadia would work:
>>>
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>>> Dave Täht CEO, TekLibre, LLC
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>

[-- Attachment #1.1.2: Type: text/html, Size: 13177 bytes --]

[-- Attachment #1.2: Screenshot 2023-01-13 at 12.29.15 PM.png --]
[-- Type: image/png, Size: 1380606 bytes --]

[-- Attachment #2: jp_starlink_irtt.pdf --]
[-- Type: application/pdf, Size: 697557 bytes --]