The system does have a function to use server/monitor pairs that are more successful (see the “selector” section in the documentation linked above). It didn’t work because of a bug (now fixed in v3.4.0)
Oops, production is running a version one commit before I made the “only active servers” change! Now fixed.
2 Likes
Hello, I have two NTP servers in Taiwan, Asia, using the Taiwan Hinet and Seednet networks respectively. I am interested in joining the new monitoring network. Is it still possible to join now?
I’ll send you a separate note, thank you!
Hi Tim; lots of good questions!
- The denser dots are just an artifact of how the graphing works. There are many more monitoring “points” now. As the old data rolls off it should show a shorter time period with slightly less data. (I’d love to fix this, but it’s temporary and I probably wouldn’t figure out the javascript before it’s sorted by itself …).
- The red dots are when the score drops significantly (typically from an i/o error / timeout). See my next post for more on this!
- The monitor names are [two letter country code][airport code].
- The acceptable offset is currently 75 ms (!). With the improved monitoring system we can probably make this smaller.
Thanks everyone for your patience with this rolling out!
I found a bug in the monitoring client that I’d introduced in an unrelated change a late Sunday evening a couple months ago. We missed it in testing because most of the beta monitors never got that particular version.
In each test the monitor sends multiple “probes” to a server. The intention is that it picks the best response it gets as the monitoring result. The bug I introduced made it so if any of the probes had an error the whole result got marked with that error, rather than ignoring it in favor of a successful response.
it’s fixed now and the monitors run by the project have been updated. The other monitors should get updated in the next ~12 hours or so.
deksf1 is in Germany. Denmark would be a ‘dk’ prefix. 
During testing and the last few days of looking at graphs I’ve seen so many examples of different monitors seeing very different (and very consistent) offsets. I haven’t seen any clear patterns of some monitors consistently working well for everyone and many examples of the same monitor getting “crazy” results for one server and excellent results for another. There might be some confirmation bias, but I think it validates the new design with the many monitors and the system trying to choose which to focus on.
Indeed – the code that generates the location code options is here.
I’d like the monitor to have a traceroute feature built in and occasionally send traceroute data to the monitoring API to help on this sort of thing.
Over the weekend I added (made public) my ntp server, the monitoring results are erratic and unstable. To be honest I can’t believe it is that worse, pinging from an out of country gives perfect results.
BTW it is an IPv6 only server …
1 Like
Thanks @ask for jumping on this and troubleshooting it so quickly. My scores have started to stabilize and my servers are starting to spend time in the pool again. If you need anything else from me let me know. If you need another US monitor, I’m willing to volunteer for that as well.
No it’s not that. The red dot by the ‘T’ of Tue represents an offset of 2000ms, which is why the score dropped 5 points. It looks like just the last two digits of large offsets are being drawn on the axis label.
I’ve got a couple servers in Hyderabad, India I could run a monitor from.
Dear @ask , I am so sorry, but I have to report that the problem is still there (crazy recentmedian score):
Screen capture a minute ago.
@willem your post isn’t helpful when you block out your IP address, there isn’t much we can tell about what’s going on without it. This is a public pool so blocking your IP address is self-defeating anyway.
Thanks!
Thanks for fixing it!
When I am monitoring your server with to command:
ntpmon 2a02:a46b:c3c0:123::94 &
(from GitHub - bruncsak/ntpmon: NTP server reachability monitoring)
it is OK most of the time, but there seems to be some missing NTP reply:
03-23 08:39 16.91 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@.@@@@.@@@@@@@@@@@@@@@@@
03-23 08:57 16.91 .@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 09:13 16.55 @@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@.@@@@@@@@@@@@..@.@@@@
03-23 09:25 16.55 @@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@.@@@
03-23 09:43 16.73 @@@@@@@@@.@@@@@@@.@@@@@@@@@@@@@@.@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@.@@@@@@@@@@@
03-23 09:57 16.89 @.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 10:14 17.05 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@
03-23 10:26 17.19 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 10:40 17.19 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@...@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 10:57 17.33 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@..@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 11:14 19.39 @.@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@.@@@@@@@@@@@@@@@@@@@@@
03-23 11:29 17.47 @@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 11:40 17.59 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@.@.@@@@@@@@@@@.@@@@@
03-23 11:56 17.71 @@@@@.@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 12:14 17.93 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@
03-23 12:26 18.04 @@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 12:44 18.14 @@@@@@@@@@@@.@@@@@@@@@@@@@.@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 12:58 18.14 @@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@..@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 13:10 17.26 @@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@.@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@
03-23 13:28 17.26 @.@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@
(‘@’ character: received reply, ‘.’ character: no reply received) It looks like it is normal not having score 20.
1 Like
Thanks @NTPman – I looked in the database (and the monitoring log and I think what happened was that the “active” monitors didn’t check your server for so long that the score got calculated based on the “testing” monitors.
It only happened once so you had really good timing! I will add more metrics to figure out if the monitors need to “run faster” (basically bigger batches) or if the serversThanks @NTPman – I looked in the database (and the monitoring log) and I think what happened was that the “active” monitors didn’t check your server for so long that the score got calculated based on the “testing” monitors.
It only happened once so you had really good timing! I will add more metrics to figure out if the monitors need to “run faster” (basically bigger batches) or if the servers to be checked have to be scheduled better. The scheduling logic is basically the same as it always was. I’ve been planning to make it more sophisticated, but wanted to manage how many things changed at once.
2 Likes