Monitoring stations timeout to our NTP servers

That is a feature in the works to have monitoring from multiple locations (like on the beta site).

NTT seems to pop up a lot when people have issues with NTP traffic being dropped…

http://trace.ntppool.org/traceroute/51.155.16.62

Yes they timeout as in the path to use UDP-packets are dropped.
As such you get a bad score.

If you try the beta-server it monitors from Amsterdam and the results are different.
A lot different.

Do not trust the NJ monitoring station as it does not have a clear path to all when it comes to UDP.

Greetings Bas.

How do I use the beta server ?

Here they are: https://web.beta.grundclock.com/nl/

We all have the same problem with the Newark monitor.
You are not alone and people are working to find the cause of the problems.

Just did a tcpdump of 8 hours for Steven to compare the results of my server and what the monitor reports.
As the monitor reports my server bad all the time, the blue-line jumps up and down like a dancer for Newark where LA and Amsterdam reported everything to be fine.

Similar problems here @ byrpi2.dynu.net: IPv6 is always super stable (once the server config is final) and IPv4 fluctuates wildly with lots of timeouts in-between…
Any hints what I could try on my side?
Thanks,
Michael

@mby Your server doesn’t look too terrible NTP-wise, although there are some issues with ICMP.

IPv4 NTP: https://atlas.ripe.net/measurements/23910167/#!probes
IPv6 NTP: https://atlas.ripe.net/measurements/23910168/#!probes

IPv4 Trace: https://atlas.ripe.net/measurements/23910177/#!probes
IPv6 Trace: https://atlas.ripe.net/measurements/23910179/#!probes

IPv4 Ping: https://atlas.ripe.net/measurements/23910187/#!probes
IPv6 Ping: https://atlas.ripe.net/measurements/23910192/#!probes

When you say that IPv4 is fluctuating wildly, what do you mean by that?

Thanks and I mean that IPv4 connections seems to have many more timeouts when probed by the pool than IPv6, which works nearly flawlessly:

Just two side questions:

  1. are these ip static ? reverse lookup shows up as normal ISP
  2. is the line symetric or asymetric ?

It‘s ISP but IPs should never change; and it‘s an asymmetric line.

Ok, thought it’s like a dial up which change the ip.

@mby What sort of traffic levels (NTP packets per second) are you seeing during the times when the score is below 10?

Thanks Steve, and it is always super-low traffic; appalling is that only the IPv4 probes break down while IPv6 is alive and kicking…
But anyways, I’ve monitored the accuracy of my server quite extensively and di some testing, so it does not appear to be a local problem, so I consider this as closed, thank you everyone.

P.S.: When looking at the beta site data, I have these statistics, so it looks like something I can’t influence, indeed:
IPv4: Monitoring Station:Newark, NJ, US (7.9)Los Angeles, CA (-49.3)Amsterdam (-0.3)
IPv6: Monitoring Station:Newark, NJ, US (19.5)Amsterdam (19.4)

@mby those are delightfully consistent problems!

@stevesommars might be able to help analyze some tcpdump’s if you can work with him. He’s been working out which [ network links / transit providers / etc ] are causing trouble and looking at the failure patterns.

Thanks @ask, I’m currently working with @stevesommars on it; we’ll keep you posted.