[Starlink] insanely great waveform result for starlink

Fri Jan 13 16:30:33 EST 2023

Here's Luis's run -- the top line below the edge of the graph is 200ms
[image: Screenshot 2023-01-13 at 1.30.03 PM.png]

On Fri, Jan 13, 2023 at 1:25 PM Luis A. Cornejo <luis.a.cornejo at gmail.com>
wrote:

> Dave,
>
> Here is a run the way I think you wanted it.
>
> irtt running for 5 min to your dallas server, followed by a waveform test,
> then a few seconds of inactivity, cloudflare test, a few more secs of
> nothing, flent test to dallas. Packet capture is currently uploading (will
> be done in 20 min or so), irtt JSON also in there (.zip file):
>
>
> https://drive.google.com/drive/folders/1FLWqrzNcM8aK-ZXQywNkZGFR81Fnzn-F?usp=share_link
>
> -Luis
>
> On Fri, Jan 13, 2023 at 2:50 PM Dave Taht via Starlink <
> starlink at lists.bufferbloat.net> wrote:
>
>>
>>
>> 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.
>>>
>>
>> I am so glad to see loss and bounded delay here. Also a bit of rigor
>> regarding what traffic was active locally vs on the path would be nice,
>> although it seems to line up with the known 15s starlink switchover thing
>> (need a name for this), in this case, doing a few speedtests
>> while that irtt is running would show the impact(s) of whatever else they
>> are up to.
>>
>> It would also be my hope that the loss distribution in the middle portion
>> of this data is good, not bursty, but we don't have a tool to take apart
>> that. (I am so hopeless at json)
>>
>>
>>
>>>
>>>
>>> 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
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230113/122c1b64/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/122c1b64/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-01-13 at 1.30.03 PM.png
Type: image/png
Size: 855840 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230113/122c1b64/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lc_starlink_irtt.pdf
Type: application/pdf
Size: 697557 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230113/122c1b64/attachment-0001.pdf>