[Starlink] insanely great waveform result for starlink

Nathan Owens nathan at nathan.io
Fri Jan 13 16:24:21 EST 2023 

They are just alternating colors to make it look pretty.

On Fri, Jan 13, 2023 at 12:37 PM Dave Taht <dave.taht at gmail.com> wrote:

> That is amazingly better than what I'd seen before.
>
> (can you repost your script? What's the difference between the red and
> blue dots?)
>
> Jonathan (or all? ulrich?), could you fire up the irtt for that long
> interval, and fire off a waveform test, pause, then a cloudflare test,
> then, if you have it?
>
> flent -H oneofmyclosestservers.starlink.taht.net -t starlink_vs_irtt
> --step-size=.05 --socket-stats --test-parameter=upload_streams=4 tcp_nup
>
> Going the full monty and enabling ecn and taking a packet cap of this last
> would additionally make my day...
>
> On Fri, Jan 13, 2023 at 12:30 PM Nathan Owens <nathan at nathan.io> wrote:
>
>> 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 at 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 at 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 at 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 at lists.bufferbloat.net> wrote:
>>>>> >
>>>>> >
>>>>> > On Fri, Jan 13, 2023 at 6:28 AM Ulrich Speidel via Starlink <
>>>>> starlink at 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 at auckland.ac.nz
>>>>> >> http://www.cs.auckland.ac.nz/~ulrich/
>>>>> >> ****************************************************************
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> Starlink mailing list
>>>>> >> Starlink at lists.bufferbloat.net
>>>>> >> https://lists.bufferbloat.net/listinfo/starlink
>>>>> >
>>>>> > _______________________________________________
>>>>> > Starlink mailing list
>>>>> > Starlink at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230113/470c51ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-01-13 at 12.29.15 PM.png
Type: image/png
Size: 1380606 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230113/470c51ed/attachment-0001.png>

More information about the Starlink mailing list