From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 9ACEC3B29D for ; Fri, 13 Jan 2023 13:09:53 -0500 (EST) Received: by mail-pj1-x102c.google.com with SMTP id v23so23173395pju.3 for ; Fri, 13 Jan 2023 10:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nathan.io; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HBBdZ9Zp9qhuvr47PUVmcrgSkJ0ffTMQuoH0L2K8Lho=; b=OSQ1+DxFRReoCQkkUyApgNrqxf1MoRJz4++QMa/01NujFKMDnGgHFHqsz3wjab1VKe Gy2uYBJTyZFpA85PSBETjhRmW6iwWF9gHNTe+jDjMcjyKWM4FX8Xib4wIUnPa/CL7tZw tMgmqSiCvvn4eBvfoJVvj52Wd9XqembpBmSJJZJ3SKMHxffjk557OaoUqDXc+DnmtzcW BZWKd1QQHt3tpzp5YtIJ7ab5t15HiyU0OdIpxz10vS2gcZVYV5sdDyD/GsVFCtxqY6SF ADrQZ9UoxU1jDVTrc+HAPBkzksJZDid64MxX/S8PPNLXF0c2JNCJVWmDP5ZaSNdWbj1R NVeA== 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=HBBdZ9Zp9qhuvr47PUVmcrgSkJ0ffTMQuoH0L2K8Lho=; b=S8CSe9mBrqcmhlEWy3qeJY7NaDNYNTnD4hccreSdh/Yp8S7ZH24qvy7UqXh7eKJ6AZ DM3y6EOxqrdDX9rwqarjdf0rgPC7ZGDxLWxKsxhKsUmr0C8jrXZ5WFr0WRDPSf+hD/BI ZxpDKMwVRLrM51dA5vkNt1W5TqntouJTVvO1vKo1qq3IIMa+5bGaEnkhRjEXmLaT6W7I Gvci3WuuOUpyIQ4oycEe3wvb18eP86yI38lL7+/UxBO+4R19HHYl6Y+7k/MiX4bD0NF1 iF/o8ctOGuLOwRlgLYHfRX4xHf/UfdIcVT/CeA7QErhN9Y390LElwV5oEcx3z1tct72B lOhg== X-Gm-Message-State: AFqh2koKWIF8iB8ZZVGIYIEIR1eDcnwSNvao06MByoOiegVFxW/9rgQA tRA6uFcJ4Qlr4XkiM0tgnn7q8RbDLd2FtWNQuqVxeW2e8D2xCERV X-Google-Smtp-Source: AMrXdXsWkFM9NCWaCtmgnaHWFnSzRSERSU72/LAtBa0xGECuC/ZoCTHo3iXzil1DYqtET/wGRLNf0kqr0H5SLtqcAQg= X-Received: by 2002:a17:90b:1f87:b0:226:e59d:305d with SMTP id so7-20020a17090b1f8700b00226e59d305dmr3585259pjb.152.1673633391973; Fri, 13 Jan 2023 10:09:51 -0800 (PST) MIME-Version: 1.0 References: <89D796E75967416B9723211C183A8396@SRA6> <3696AEA5409D4303ABCBC439727A5E40@SRA6> In-Reply-To: From: Nathan Owens Date: Fri, 13 Jan 2023 10:09:40 -0800 Message-ID: To: Jonathan Bennett Cc: Dave Taht , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000d0329a05f229233f" 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 18:09:53 -0000 --000000000000d0329a05f229233f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ll run my visualization code on this result this afternoon and re= port 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?us= p=3Dshare_link > > Jonathan Bennett > Hackaday.com > > > On Fri, Jan 13, 2023 at 11:26 AM Dave Taht 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 >> 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 m= e >> >> > 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 Starli= nk >> >> 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 cr= ow >> >> flies. Read: My dishy can use any satellite that any of these three c= an >> >> see, and then depending on where I put it and how much of the souther= n >> >> sky it can see, maybe also the one in Hinds, 840 km away, although th= at >> >> is obviously stretching it a bit. Either way, that's plenty of option= s >> >> 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 th= e >> >> 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 an= d >> >> 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 ho= me >> >> 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 al= so >> >> 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 broadban= d >> options. But there are also many people that live outside cities, and th= e >> 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 whateve= r >> 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 inevitab= ly >> >> 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 shoul= d >> 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 rate= s. >> >> >> >> 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 highe= st >> >> and lowest rates for each ISP. Did MyRepublic just get lucky in my >> >> tests? Or is there something systematic behind this? Way too few test= s >> >> 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 o= n >> >> my deck). Still good enough for a lengthy video Skype call with my >> folks >> >> in Germany, although they did comment about reduced video quality. Bu= t >> >> maybe that was the lighting or the different background as I wasn't i= n >> >> 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-69813666= 65607352320-FXtz >> Dave T=C3=A4ht CEO, TekLibre, LLC >> > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --000000000000d0329a05f229233f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ll run my visualization code on this result thi= s afternoon and report back!=C2=A0

On Fri, Jan 13, 2023 at 9:41 AM Jona= than Bennett via Starlink <starlink@lists.bufferbloat.net> wrote:
The irtt command, run with normal, light usage:=C2=A0https://drive.google.com/file/d/1Si= VCiUYnx7nDTxIVOY5w-z20S2O059rA/view?usp=3Dshare_link
<= div>
Jonathan Bennett
Hackaday.com


On F= ri, 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
<sta= rlink@lists.bufferbloat.net> wrote:
>
>
> On Fri, Jan 13, 2023 at 6:28 AM Ulrich Speidel via Starlink <starlink@list= s.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 f= inally
>> got around to set it up. It's on a roaming subscription becaus= e our
>> badly built-up campus really isn't ideal in terms of a clear v= iew of the
>> sky. Oh - and did I mention that I used the Starlink Ethernet adap= ter,
>> not the WiFi?
>>
>> Caveat 1: Location, location. I live in a place where the best Sta= rlink
>> promises is about 1/3 in terms of data rate you can actually get f= rom
>> fibre to the home at under half of Starlink's price. Read: The= re 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 P= uwera,
>> 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 thre= e can
>> see, and then depending on where I put it and how much of the sout= hern
>> 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? Eas= y: 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 vi= ew for you
>> because it'll also be in view for the teleport. Pretty much an= y 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 availabilit= y of home
>> broadband is like in the Dallas area. I note that it's at a lo= wer
>> 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 me= ans
>> that competition for bird capacity can't be too bad - for what= ever reason.
>
> I'm in Southwest Oklahoma, but Dallas is the nearby Starlink gatew= ay. In cities, like Dallas, and Lawton where I live, there are good broadba= nd options. But there are also many people that live outside cities, and th= e options are much worse. The low density userbase in rural Oklahoma and Te= xas 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 h= ops
>> 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 ge= t
>> dropped. The insidious bit here is that a lot of them will be betw= een 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 o= f a few
>> Mb/s where it's obvious where the dominant long latency bottle= neck in
>> your TCP connection's path is. Read: It's pretty hard to t= ell whether a
>> drop in "speed" is due to a performance issue in the Sta= rlink system or
>> somewhere between Starlink's systems and the target system. >>
>> I see RTTs here between 20 ms and 250 ms, where the physical laten= cy
>> 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 inevi= tably
>> 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 y= our
>> cwnd is immediately after a handover, it's probably not what i= t 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 t= hat
>> Starlink seems to be buying its local connectivity from (Vocus Gro= up)
>> 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 r= ates.
>>
>> Another ISP (MyRepublic) scored between 11.81 and 21.81 Mb/s up an= d
>> between 106.5 and 183.8 Mb/s down, again with RTTs badly correlati= ng
>> with rates. Average RTT was the same as for Vocus.
>>
>> Note the variation though: More or less a factor of two between hi= ghest
>> and lowest rates for each ISP. Did MyRepublic just get lucky in my=
>> tests? Or is there something systematic behind this? Way too few t= ests
>> to tell.
>>
>> What these tests do is establish a ballpark.
>>
>> I'm currently repeating tests with dish placed on a trestle cl= oser to
>> the heavens. This seems to have translated into fewer outages / pi= ng
>> losses (around 1/4 of what I had yesterday with dishy on the groun= d 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&= #39;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 m= y dishy mounted on the back fence, looking up over an empty field, so it= 9;s pretty much best-case scenario here.
>>
>>
>> --
>>
>> **************************************************************** >> Dr. Ulrich Speidel
>>
>> School of Computer Science
>>
>> Room 303S.594 (City Campus)
>>
>> The University of Auckland
>> u.sp= eidel@auckland.ac.nz
>> http://www.cs.auckland.ac.nz/~ulrich/
>> **************************************************************** >>
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starl= ink
>
> _______________________________________________
> Starlink mailing list
> St= arlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink<= /a>



--
This song goes out to all the folk that thought Stadia would work:
https://www.= linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXt= z
Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--000000000000d0329a05f229233f--