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 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@lists.bufferbloat.net> wrote: > >> >> >> On Fri, Jan 13, 2023 at 12:30 PM Nathan Owens 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 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 >>>>> 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 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 >>>>> >>>> >> >> -- >> 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 >> >