I think I spoke just a little too soon. It just dive rocketted biggly
Still not much improvement for me here in Melbourne, Victoria, Australia on AS1221 (Telstra).
IPv4 score: https://www.ntppool.org/scores/203.52.62.212
I’ve enabled IPv6 on the same server and it has a much better score.
https://www.ntppool.org/scores/2001:8000:24ef:3009::123:1
The Zurich monitor on the beta is seeing far fewer lost responses, and I have a score of 20 on both IPv4 and IPv6.
It’s hard not to conclude that there is still an IPv4 routing or packet loss issue between the LA monitor and me.
My issues persist, off and on, as well. Some days are totally fine, others my servers are being yanked from the pool off and on (because of the LA issues).
I feel like there is a pretty regular pattern to it. This is three days worth of scores.
There also seems to be a clear issue monitoring UDP over long network links and in the quality of various provider’s networks.
I see the same problems that others see. And I don’t understand what’s happening here.
When looking at the beta I see Zürich performing great. But Zürich, only! The graph looks somewhat ridiculous 
When looking at the firewall I see clients happily querying the time source.
What is wrong with our setup? Or what is wrong with machines in LA?
I see the discussion but up to now I believe there are no solutions. And I am not sure if it makes sense to further join the network if I cannot be of benefit for clients because the monitoring station puts me out of business.
How about the stations in Luxembourg or Hollywood? When will they be active? They could give us some more understanding. Maybe it works better if servers in Europe use monitoring stations in Europe… I don’t know.
The suggestion to let decide which station should be used for monitoring looks really reasonable to me.
We are having the same problems with the Los Angeles Monitoring Station, there must be something wrong with that station.
IPv6 is no problem but IPv4 is a problem with Los Angeles, Monitoring Station Zurich is fine with IPv4 and IPv6
One of mine has been rocks solid, the other seems to be experiencing the same dips as many others. Must be some unreliable or overloaded link somewhere in the interwebs.
In the meantime I set up a filter that moves all mail regarding ntp problems into the trash folder. This is my way of handling it, because I can’t do anything against it. And I really don’t like trashing these mails.
I understand that these issues do not have a very high priority. But what can we - the ones affected - together - do to find the problem’s source and get rid of it?
@ask Is there anything we can do to help or support you?
I don’t think that the current scoring system is the best way of handling it. Because one route to/from your monitoring station being (sometimes) bad does not mean that other routes to/from ntp clients around the world to the pool servers are evenly bad. On the other hand your route to/from your monitoring station being good does not mean that other clients around the globe don’t have problems reaching a pool server. It’s nothing more than a hint. Why not use multiple monitoring stations and weight the score considering the region the pool server is located in? Maybe this is what the beta is supposed to do. Even if there are currently no more than one monitoring station abroad in place (Zürich), isn’t it better to take this one into account than throwing out the pool servers?
The multiple-monitoring station thing is currently in beta right now… Have you signed up on the beta site to add your server and see how it scores there?
Yes, ofcourse. Pls see #46 (or 45?) above.
My mistake. I swear I scrolled up to look before replying, don’t know how I missed that post / attachment. Curious how only Zurich shows a positive score out of the multiple monitoring stations.
I was having similar issues, then the other day I happened to run ‘ntpq -p’ on my server just to see the stats and was shocked that some of the servers were way off. I’m guessing network issues somewhere. But I guess NTP was jumping around not really sure which group was the correct time, and when it did my score would drop on the monitoring page.
I had to go through quite a few servers before I got enough that agreed on the time and were stable. Once I solved that problem my score has been steadily going back up on the monitoring page fingers crossed.
I realize it’s a long shot, but if you don’t watch the ntp server list stats regularly, it might be worth checking on.
Following up on my previous posts for 81.174.128.183
I suppose it is some consolation that it seems quite a few others are seeing similar issues… Anyway, I found some improvement after disabling ‘Port Scan and DoS Protection’ on my router, but didn’t solve it completely. As my scores now do occasionally get above 10 I thought I would put it back in the Beta Pool - and, although I haven’t reviewed a large amount of history, I can see that the timeouts occur just on the LA monitoring system but Zurich seems to be fine. Ah - having said that, I’ve just now seen one i/o timeout for Zurich, but it doesn’t change the point that Zurich is much better.
I am left wondering if the difference is related to the routing to the two monitoring locations or to do with the fact that the Zurich one does three samples.
Hi thanks for the reply, i have tried changing my peers although it does not seem to change much. I think it must be a network issue between me and the monitoring station. I wish it was slightly more forgiving.
Still experiencing the issue. After looking at the logs it looks like its the io/timeout error everyone else is experiencing. https://www.ntppool.org/scores/81.174.133.68/log?limit=200&monitor=* Not sure what to do really. Does anyone know the current IP of the monitor?
It looks like scoring system really suffers from being located only in US.
I have listed both ipv4 and ipv6 of the same server (hosted at Scaleway @ Netherlands), and they are getting drastically different scores, with ipv6 being much better (!!!???). Currently ipv6 has score of 6.5, and ipv4 has score of -19.2.
Servers are 51.15.74.121 and 2001:bc8:4730:940e::1
We are seeing this be an issue as well, and I think it is because of the monitoring station being US based.
We have an NTP server running on a dedicated 100mb/100mb fibre loop. Using the NTP Server Test at https://servertest.online/ntp we consistently get good results, but from the NTP Pool monitoring station we are getting scores of -88.6!! I cannot fathom why. The CSV (https://www.ntppool.org/scores/62.254.125.171/log?limit=200&monitor=*) shows I/O timeouts but I don’t see why - the server is up, accepting connections and available. There is no traffic being put down the connection (apart from NTP), so the only conclusion I can draw is that the network between us and the monitoring station is providing an extreme/excessive amount of latency. Querying the NTP server from within the UK, where it is based, returns very quick responses and we certainly aren’t seeing I/O timeouts.
This is a real shame as we would like to provide resource to benefit the NTP Pool project. As far as we can see we have done everything right, it’s just factors outside of our control that seem to be stumping us.
Well, there seems to be something dropping the traffic. I don’t think this is only a NTP Pool monitor node issue. Stats from Finland: http://orava.miuku.net/stats/ntppacketloss-62.254.125.171.html