Does all zones serve US requests?

Nope, sorry, not true. As said multiple times before, the mechanism by which monitors learn about the targets they shall monitor, and how (e.g., with what frequency), is separate from the GeoDNS mechanisms by which servers get assigned to “real” clients.

Again, you don’t, but others do.

Not sure how that is relevant in this context.

Yes.

No, not “like any other” at least as far as mapping of clients to servers is concerned. The mapping of monitors to servers follows different mechanisms than the mapping of “true” clients to servers.

Sure, but that is because the monitoring also uses the NTP protocol, i.e., the packets are pretty much indistinguishable from “normal” NTP packets*. But that has nothing to do with whether they show up in the GeoDNS statistics, or not. And monitors do not show up in those GeoDNS statistics, because the monitoring system does not use the GeoDNS system, but a separate distribution mechanism (as said multiple times now).

* People who are very familiar with the behavior of different types of clients might be able to detect them by some characteristic. Would be interesting whether they have a specific, detectable fingerprint, like many other client implementations do.

Sorry folks, maybe I have a misunderstanding?

I thought, that the statistics shown for some countries originates from the geoDNS server’s DNS traffic analysis, and not from the NTP service monitors.

In my original understanding what counts for the above server’s statistics accounted to us is a DNS query where the DNS client is located in the US, and the query is for za.pool.ntp.org or africa.pool.ntp.orgor for some other country zones where there are not enough NTP servers AND in the DNS answer the server IP 160.119.230.39 appears.

1 Like

Yes (as in that is my understanding as well).

Indeed (as in that is my understanding as well).

I think the misunderstanding could stem from some people thinking that the monitors also use the GeoDNS system to find servers to monitor (in which case their queries would indeed also show up in the statistics). But as mentioned before, the monitors do not use the GeoDNS system to find servers to monitor, so there are no queries from the monitors that would end up in the GeoDNS system’s statistics.

Yes (as in that is my understanding as well).

Or for other names, and/or in circumstances where it is currently not known how they could return the server in question for a query from a client in the US zone.

The issue is that it currently looks like the number of queries from the US zone to this specific server (but also others, or in other zone combinations) seems too high to be due to those queries you mention alone, so people are trying to understand why the numbers are so unexpectedly large.

“people” being me, nobody else seems to notice? Or worry about it.

Also, why only US?

I don’t understand shit about it anymore.

I’m with the pool for a long time.

It has problems. Monitors was fixed after I fought about it for long.

That was fixed. DNS-round-robin is crap. Sorry to say.

I noticed, at least for other countries, as mentioned. E.g., with IPv6 for my servers in The Netherlands and Lithuania. And only recently noticed that traffic from CN by far exceeds local traffic for IPv4 on my Singapore instance.

At least on my servers, it did not reach a level that would worry me, in the sense of creating problems.

Bandwidth in Asia is generally rather expensive, so I have started to wonder as to how to potentially reduce traffic from other zones so as to increase how much local traffic I can serve.

Generally, while not “worried”, as mentioned still rather curious to understand what is going on, certainly in “strange” (to me, and you, too, I understand) cases like your server getting hit from another continent, and a specific country, at that level. Or my instances in NL and LI getting hit from Germany. (I think I have a good enough guess as to why the instance in SG is hit so hard by clients from CN, given that CN is arguably the most underserved zone I am aware of.)

Indeed, as mentioned, very curious (but not worried, unless this is causing actual issues on your end).

Glad you finally realized this, after disputing for the longest time that there is such a thing as what other people call “underserved zone”. Now that you’ve experienced the effects first-hand yourself, you hopefully understand what issues people experience where the 512Kbit setting does not only generate single-digit Mbit/s of traffic, but even up to triple-digit Mbit/s. Making even servers of universities and big Internet companies struggle, let alone small private ones like yours, or arguably the majority of servers in large parts of Europe and North America, which the pool is implicitly biased on serving primarily.

Not causing issues for me. In-fact, I wish I could increase traffic. I assume that ZA is over served? I don’t go above around 0.65X my “3Gbps” local capacity, with a total of 5000pps. But most monitors suffer as they have a RTT of 200ms to 400ms(and that gives bad scores and says that my time is 500ms slow?), so it’s not like I can assist elsewhere…

Ok, good.

Yeah, same here for some of my servers. You could pick some nearby zones with only a few servers in them, and ask at server-owner-help@ntppool.org whether they can add those zones to your server. Though note that as others have also experienced, for some reason, it is a bit like lottery as to whether a request will be processed, and when (slightly better than real lottery, actually, but still not really understandable why somewhat frequently, and somewhat randomly, requests fall through the cracks).

Also, pool staff seem to be predominantly located in well-served zones, without any experience of how difficult life can be in underserved zones, and that clients in such zones might prefer to get service from far away servers, rather than getting crappy service from local servers (and local operators might be welcoming additional capacity offloading their servers, or allowing additional smaller servers to join, like happened in Bas’ case in Belgium). So as others seem to have experienced as well, staff refuse to add zones that they consider “too far away” from the server. (But clients are obviously free to explicitly configure far-away zones if that raises the perspective of getting decent service from the pool - potentially explaining why the countries with the second-largest and third-largest shares of traffic on my server in the UK are China and the Russian Federation, even though traffic from the UK still is first by a large margin.)

I wouldn’t say over served, but certainly among the better-served zones globally. I’d expect a personal server at a 512Kbit setting might still get too much traffic to join, similar to Bas’ before the other servers helped out in the BE zone, with now slightly less than 3000pps for BE and NL, and IPv4 and IPv6, combined. (Slightly more than 2000pps in Germany, slightly more than 3000pps in France, almost 4000pps in the UK, slightly more than 4000pps in Spain, almost 9,000pps on the East coast of the USA, and more than 10,000pps on the West coast of the USA – all of those current short-term snapshots as of right now, so might be higher or lower on average.)

That number suggests a well-served zone.

Hmm, as of right now, I don’t see that the monitors would generally give bad scores to your server, or say that your time is generally off by too much. There always is the odd outlier, or a few where for various reasons, the offset is unusually high (or where there is noticeable packet loss).

On the one hand, that is why there are now more servers, and in somewhat more diverse locations (though the pool is still strongly biased against what are typically underserved zones, e.g., by selecting references for the monitors primarily from North America, Europe, Japan and Taiwan, thus putting monitors outside those regions at a disadvantage, e.g., in India).

On the other hand, it has previously been suggested that the scaling of the graph should perhaps be based more on the majority of monitor results, rather than having a single, or a few outliers blow up the entire graph.

Not at all. It’s just that in somewhat recent past experience, pool staff refuse to allow that (while some zones, such as China, still have a notable number of servers from “far-away” regions helping out from when that was still accepted). Despite being reiterated time and time again in this forum that larger RTT is not necessarily an issue (though obviously, statistically speaking, likelihood for path asymmetries and packet loss increases with larger RTT), and despite people in underserved zones potentially preferring to get served by a server that is further away, rather than getting crappy, or no service, from a local server.

Yes, that is annoying, I wish sometimes I can permanently remove the candidate monitors from my graphs. From monitoring on my appliance, I know that my time is correct to ±3ns, so when a monitor tells me that my time is 500ms wrong, then it is a fact that it is the monitor’s perception of my time that is wrong, not my time.

:person_facepalming: I can request to assist zones in Africa. It is annoying that I can’t see if 1 server is enough in a zone though. Africa does not necessarily have many users in a zone as some zones can be under developed, but I did put in a request to assist a neighboring country which only has one server.

1 Like

Unfortunately, it’s precisely the “perception” that is of importance since this is what a potential NTP Pool Client could see when they would request the time from your server from that particular zone.
However, i totally agree with your feelings on the graph scaling and not being able to customize it and remove some of the ouliers…

What is the relevance to local and regional clients of a monitor, e.g., from the USA, Australia, or even Europe perceiving there to be a big offset for a server in Africa, or Asia, when compared to local/regional references, or based on its advanced setup with GNSS-disciplined OCXO or atomic clock, the server is perfectly fine?

But then only monitors from my continent should monitor me? As I’m only supposed to server clients from my continent? But i know that isn’t feasible as there might not be enough monitors in Africa.

Also, does the monitors use sntp or full ntp? To my understanding sntp does not mitigate RTT as well as ntp does, so, even if normal clients use sntp(and that is their choice), monitors should be using full ntp to monitor servers?

No, obviously, that is not feasible currently. But that also wasn’t my point.

Rather, that the perspective of local/regional clients is more important than that of some potentially far-away monitors, which are currently predominantly located in European, North American, and a select few Asian and Oceania-based locations.

And even if outside of those, monitors are measured mostly against references from those regions, sometimes preventing more localized monitors from actually contributing, thus in turn preventing servers of being assessed more from the point of view of what local/regional clients would see, depriving those clients of servers that actually would work well for them if they weren’t measured from a predominantly European and North American perspective.

Besides the score as actual measure of performance of a server, the RTT from monitors to a server is already being considered to prefer assigning more local monitors to monitor a particular server, which is a very good thing. Something similar, probably less over-engineered than the monitoring system for servers, might be helpful, i.e., when vetting monitors (which is done continuously), give higher weight to more local references, and make it less likely for far-away references to prevent a monitor from operating as monitor.

And other steps to foster more diversity in monitor locations. E.g., a server host is only eligible to run monitors if they had a server in the pool validated at least 18 months ago. However, in underserved zones, it is difficult to actually set up a server, which in turn restricts how many monitors can be set up. More exceptions should be granted, on a case by case basis, to set up monitors even when the aforementioned precondition isn’t met.

Or foster server operators that meet the precondition to “sponsor” monitors hosted on infrastructure of operators who themselves do not (yet) meet the precondition themselves. I.e., a sponsor would assume responsibility, and ensure in cooperation with the infrastructure host, that the monitor is operating properly, and pull the plug if it turns out that a location is not appropriate after all (from perspective of how it would support the local/regional community, not primarily how far-away references assess it).

Each client is responsible for their own vetting of time they get. The pool is doing just basic sanity checking, and kicking out servers that do not meet some basic requirements. Trying to replicate the functionality of a full NTP client on the pool side would not only overload it from a functional point of view, but it would also not really work, and instead give a false sense of security. Because it cannot continuously assess any and all clients’ views so as to shield any and all clients from any and all misbehaving servers at all times (unless one would attempt to turn almost any and all “normal” clients into monitors so as to be able to assess what they see).

In my servers, it’s both the US and CN which haunt them. Since my servers are not part of the global pool, i cannot help concluding that the pool serves addresses poorly. Alas, it serves IPv6 awfully.

1 Like

Perhaps through europe.pool.ntp.org?

Yeah, could be another contributor. Though not sure how many people use the continent zones, rather than the country or unnamed zones. My guess would be that more people in DE would explicitly configure the NL zone rather than the Europe zone, but who knows…

Candidates have no impact on your score and do not decide if you are in the pool or not.

They are just selected to see if they are good candidates to monitor your server, when they are they move to testing, for a better test.

If they pass testing they are assigned to monitor your server for scoring.

Candidates are just the monitors that could step up, but probably won’t for your server if they are too much off or simply too far away.

Do not worry abou the monitor-system, it’s pretty solid and only the selected score you….until they go bad and others are selected. All in all, only the best monitors for your system will score you.

Yes, aware of that, but they pollute my graph, and mess up the scale when one candidate says my server is 500ms off and everything useful shrinks to a little section of the graph.

I agree on that, but it does show how your routes to the rest of the world look like.

I have installed my own graphs, far better.

Candidates should not graph unless you explicitly tell them to show dots, would be better.

Something to wish for :rofl: