I notice by far the worst-looking score curves in the graph when I foolishly break my pool server running test code are coming from ,every, lines in the .csv logs, which I surmise represent the legacy scoring. Given they don’t have a line in the monitors listing to highlight them, they’re a bit mysterious to the casual observer.
Since they distort the logarithmic scale and aren’t used anymore, I wonder if it would make sense to not graph them, or not calculate them at all.
It would also be spiffy if one of the monitor developers (heh) had time to look at not using monitors which are score outliers as they also distort the Y scale. See for example:
where it seems usewr1 and belgg2 appear to suffer similar rates of packet loss to me when the rest of the monitors are seeing none, leading to scores that hover around -50.
You can not tell if a monitor is wrong because you see wrong scores for you.
As Belgg2 scores fine for systems in Europe.
Some routes to other parts of the world simply don’t work well.
I has the same problem to me from the San Jose single monitor of the previous system.
If my monitor keeps being bad for your system, it will be removed for monitoring for your server and as such set as ‘non-score’ monitor, however it still shows, but it doesn’t influence your NTP-server being used in the pool or not.
Also, it shows you that some routes from your server don’t work well to Europe.
This the reason I was hammering @ask to build a new system with multiple monitors, so people are NOT scored wrongly. It did before.
Ps. my monitors end with: 19sfa9p
Ps2. I seem to score your IPv6 port just fine, it’s the same server-monitor
I agree with everything you said, with one exception. The seriously outlying scores belgg2 shows that some routes to and from my server via IPv4 to and from one provider in Europe don’t work well.
Likely the reason belgg2 scores my server’s IPv6 address well is I use a different ISP for IPv6, as my local provider is, despite being founded in 2020, IPv4-only. I’m using a free he.net tunnel, which to my delight can still manage hundreds of megabits, in spitting distance of my IPv4 throughput.
I use 2 servers for monitoring. Belgg1/2 and Nlams1/2 both ending at 19sfa9p
It’s UDP, UDP has no packet-acknowledge, so if packets are filtered of dropped for some reason they are not resend like TCP does.
The other reason could be the UDP-packet takes too long to arrive at the monitor, as such being suspected as being dropped (time-out limit).
I would not worry about that. Your server is fine, just not for my monitor. Shit happens
You seem to have missed the point of my original post. I am not worried about a few monitors having suboptimal connectivity to a pool server of mine. I was requesting the pool server graphs not have the logarithmic Y axis for score blown out by that (or by the legacy score).
My wording was poorly chosen. In saying “not using monitors which are score outliers” I meant only not graphing outlying scores.
BUT draw the scoring monitors in e.g. black and the non-scoring in yellow.
So you see them, but you have to look better, yellow on white isn’t the best of combination.
But hey, they don’t score you.
Then your graph would ‘look’ better
I agree on the graphing, but different colors should be used.
Yeah, I agree that the “every” score isn’t useful anymore. I needed it in the beginning after changing the scoring so I had a path to easily roll back.
I agree with you both that the graph could use a lot of improvement! I haven’t had time for that.
Working in javascript is really slow for me and I haven’t done anything meaningful to the graphs since many years ago. Touching them will likely include dependency upgrades and various cleanups.
It occurs to me that it would be nice to have an option to have the SVG graph show only active monitors, perhaps with a checkbox by the testing table headline. I spent a bit of time spelunking the javascript from the browser and was overwhelmed, not least because I have little experience with it, and it’s probably “minified” so the variable names are short and not terribly descriptive.
I assume it would be easier to understand looking at the original source, but I don’t see it in ntppool · GitHub. Is the source available somewhere?
