I’ve worked on a number of NTP loss problems. Tools like mtr and traceroute can sometimes identify where packets are being dropped. Tracing the NTP request or response may be needed, depending on which is lost. For NTP request losses those tools should be run from the NTP client. For NTP response losses those tools should be run from the NTP server.
I typically run traceroute towards two different target UDP ports, e.g., 123 and 53. Comparing the two may show evidence of blockage / rate limits.
The bigger question is “what next?” I’ve seen NTP filtering problems with CenturyLink, Telia, Zayo and others. They don’t respond to my emails. The people doing the deliberate NTP filtering (rate limiting) feel that it is a necessary DDoS mitigation. There seems to be no dialogue with the NTP community to lessen the time transfer impact.
Note. Using the “–udp --port 123” options mtr version 0.92 worked as expected. An older version, 0.85, did not use UDP port 123 probes. I don’t know when the behavior changed.