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 >