New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
We do use it, but yes, our logic allows other DBs to override ipinfo if they have a majority. I'll look into this issue and PM you
It's a very niche scenario so no top priority, but I think it's fine to be able to select the country from each db (auto-city/geoip using the algo is totally okay, just be able to fix these weird scenarios)
I also found out that many (and I really mean many) of my probes have France in the country selection. I have no clue from which db this comes from, but very strange.
I went and added a handful of probes, could you get me added to the leaderboard please? Same username.
@sh97 anddd meee please to the leaderboard, same username.
Will get it done one of these days
I see my name on the list already.
Chat I'm back.
4 losses during the mental breakdown last few weeks.
@sh97 add me to the leaderboard page with the same username.
Hey Dimitry, nice to meet you.
FYI, if you are going to implement a majority override implementation in IP geolocation selection, you likely will not benefit much from using our data in many cases. We use active measurement-based geolocation. Kinda same thing we are discussing here, but currently have 920+ servers dedicated entirely to active measurements.
Traditionally, IP geolocation is based on more of a data parsing service from geofeed and WHOIS data. So, the rest of the industry is going to have consensus on many IP addresses as they all use the same data, which is ASN/ISP self-reported data.
In those cases (I would not say edge cases as this is quite prolific), our data is not going to agree with the rest of the industry because we are right, the rest are simply wrong. We highly do not recommend using consensus-models for doing IP geolocation through selecting multiple data providers.
We did run many tests and while ipinfo was correct in many cases, it was also often wrong.
The current algorithm gives ipinfo priority but still allows other DBs to override it and based on our tests it resulted in higher accuracy overall.
And btw, I would love it if we could run our probes on your network of servers
Thank you very much.
This is really interesting. Can you flag these IP addresses for us in any way? I would really appreciate that feedback. We will investigate each issue thoroughly.
I will talk with the team, but it will take me a while to push the request through. A very limited number of team members (like ~1.5 regular people) manage these 920+ servers. So, we operate it very conservatively.
Adding new features is very tough for us because maintenance, marginal improvements, and expansion take up most of our time. I hope you understand.
Latency tests can work but they can also be an entire clusterfuck.
Like, try to geolocate an IP in Europe, good luck.
We are aware of that. For example, SDWAN. Although it is our primary data, latency data is just one of many data points for us. We have dozens of locations in Frankfurt, Amsterdam,
London etc. to address the latency-related challenges. We have the data and are aware of our shortcomings and we are working on improving it.
We are forming a great research team and we form and consider new ideas for IP geolocation and IP data in general. We are less than 60 people and we have several literal internet scientists across our data and research team.
The ProbeNet generates the data for us, then our research and data team take that data and make better inferences. Even though it makes us better than everyone else but our goal is to get as close to 100% as possible. We are trying, trust us, it will keep getting better.
Another aspect I have to point out that helps is talking with our users. Like I am literally talking to the creator of JSdelivr in this thread. I am also familiar with your Yaammdb and Looking Glass project. You are an awesome guy as well.
You guys can show me things that I never knew before. Taking feedback does help us a lot and point out where we can improve things.
Free bump aka year later I bought an sdcard and revived probe.
Should have done it much earlier with Amazon free one day shipping to Paczkomat ffs, my bad, sorry
I also somehow needed to adopt my probe two times. I did it once on
dash-directus, set some additional settings and 3 minutes later it was gone. Adopted it once again viadash. Showing only once in my list of my probes... but twice in log, I am not seeing things.I hope I didn't break anything :-D
You really shouldn't be logging in the directus panel directly
Use the normal dash.globalping.io
But it should all be good
You can now analyze the geo location of your probes against all the geo DBs we're using and report any issues using this tool https://geodebug.globalping.dev/98.98.170.188
And if there are any AI fans over here you can also connect to our remote MCP server https://blog.globalping.io/ai-global-network-access-globalping-mcp-server/
reguards
I am still not tracked by globalpi.ng
Some questions aka free bump.
EDIT:
Seems I had to adopt probe again. It went "offline" 2 weeks ago (?).
Are those hardware probes really adopted "per IP" and when IP changes it goes away? It's not based on some kind of hash of hardware things? mac+cpu+idk?
Not at the moment, only to fail the v6 ping test. But I guess that's what it's doing, you can just ignore the logs if that's the issue.
Shouldn't be happening. Send me the probe IP to check
Indeed, thanks letting me know
Older firmware were only IP based. But it should be smart enough to handle IP changes unless the probe was offline during the IP change. Try upgrading the firmware if you can. You can also PM me the details to check the logs
Same here
@sh97
Thanks for tag - will get em added soon