<div dir="ltr"><div>That's very brief gaps between starlink satellites, the network is still sparse. I have a smokeping instance at the same site on a 60s interval, packet loss to the default gateway is averaging between 0.25 to 0.85% over 4 hour periods. Periodically there are antenna maintenance and firmware updates at 0200-0400 local time which cause downtime of anywhere from a few minutes to a few hours.</div><div> </div><div> </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 26, 2021 at 12:47 AM Romain Fontugne <<a href="mailto:romain@iij.ad.jp">romain@iij.ad.jp</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eric, Thanks for sharing that, I didn't know about that probe. I amazed by the stability of its last mile RTT (see attached graph LM36492). It looks like the probe is loosing connectivity to RIPE controllers once in a while, do you know if this is caused by starlink or is it other running experiments? Cheers, Romain On 3/26/21 10:32 AM, Eric Kuhnke wrote: > There are a number of instances where probes based on a satellite ISP > may be wildly different in geographical location vs. IP location. > > For instance I have previously run systems in Afghanistan on > geostationary satellite capacity, where the other end of the link was in > Singapore. All of the IP adjacencies and transit, peer uplinks were in > Singapore. > > This is fairly normal for anything geostationary. Systems based on o3b > (a MEO satellite network owned by SES) can also have wildly divergent > physical and logical locations. > > I have a probe running right now on a SpaceX Starlink beta test terminal > ( <a href="https://atlas.ripe.net/probes/1001821/" rel="noreferrer" target="_blank">https://atlas.ripe.net/probes/1001821/</a> > <<a href="https://atlas.ripe.net/probes/1001821/" rel="noreferrer" target="_blank">https://atlas.ripe.net/probes/1001821/</a>> ) which is logically in > downtown Seattle, but is physically in a rural eastern suburb of > Vancouver, BC. > > With the growth of Starlink, OneWeb, Kuiper and such in the future this > issue will become more prevalent. > > > > On Thu, Mar 25, 2021 at 6:03 AM Massimo Candela <<a href="mailto:massimo@us.ntt.net" target="_blank">massimo@us.ntt.net</a> > <mailto:<a href="mailto:massimo@us.ntt.net" target="_blank">massimo@us.ntt.net</a>>> wrote: > > [possibly OT] > > In 2018 we found 18 probes which were located so far from reality that > the collected RTT towards targets of known locations was faster than > the > speed of light (I remember we did something about those). I suspect > there are some cases more, just below speed of light. But not so > many, I > believe the vast majority of the probes are all set properly. > > With software probes there is also the problem of less users > reporting a > location at all (I don't have numbers, based on an observation in a > past > experiment. It may no longer be the case). > > I don't remember if there is something similar already in place, but I > would suggest a process like: > - if a probe doesn't have a location, set a location calculated by > latency measurements AND ask the user to review the result at is first > convenience; > - for all the probes currently having a location, use latency > measurements to mark the one possibly wrong and ask the user for update. > - overall, use latency measurements to periodically review the probe's > location. RTTs can be used to mark obviously wrong locations, without > being too restrictive. > > For RTTs above a certain amount (the usual 10ms?), deactivate the RTT > validation so users are still able to place probes in exotic locations. > > I don't think there is a use case for obfuscating probes more than at > the city level. And if there is, these probes should be tagged as such. > > Ciao, > Massimo > > On 25/03/2021 13:00, Ponikierski, Grzegorz via ripe-atlas wrote: > > I would add to it additional problem that some hosts obfuscate probe > > location even more. For example you can find probes which in > reality are > > located in US but are marked as CN or probes which are in reality in > > Wisconsin but are marked in California. Of course these are extreme > > cases. I guess most hosts just put a pin with probe location just > > somewhere around where it's locate as long it's in the same city. I > > don't remember, as a host of 3 probes, to get any precise > > recommendations how to mark probe location. Personally I just put > a pin > > in city district where probe is locate. > > > > Regards, > > > > Grzegorz > </blockquote></div>