It seems to constantly reporting a score of -0.1, but on pool.ntp.org: Statistics for 62.2.85.186 the recentmedian score is
fine with ~20, the legacy score shows quite often different values. This
is an IP address which has a long history of often being difficult to
reach from the previous monitoring system. It seems that some of my ISPs
transit carriers are doing some filtering / DDoS protection. This can be
seen with around half of the scores in ātestingā being negativ.
Could it be, that the score in the json output still does use āoldā (or
even stale) data? The IP 62.2.85.186 had a too low score since 13th
March 2023, so before the new monitoring system went into operation.
Oh, you are right, I could have checked that on my own.
So I guess another thing for Ask to investigate and fix then.
To enlighten people not familiar with such things. The timestamps are in
seconds since the Epoche (01.01.1970 00:00 UTC), to get an
understandable date use below commands depending on your OS.
On BSD-style systems (including macOS):
% date -r 1679120256
Sat Mar 18 07:17:36 CET 2023
% date -r 1679120034
Sat Mar 18 07:13:54 CET 2023
With GNU date (on Linux systems):
$ date -d @1679120256
Sat 18 Mar 2023 07:17:36 AM CET
$ date -d @1679120034
Sat 18 Mar 2023 07:13:54 AM CET
How odd! Skimming the code I think I see the bug, maybe, but I donāt understand how it ever worked ā many of the relevant bits are ~10 years old. Iāll see if I can fix it this weekend. A github issue referencing this thread would be welcome.
Thanks @fab23 ā it should be fixed now (on the beta site and production site both).
The old monitoring system created a history with a NULL monitor_id for the scorer. What happened was that you before got the last value from the old scorer (until that expired into the archive history which isnāt currently available through the API). I fixed it so if you donāt specify a monitor_id itāll choose the ārecent medianā scorer.
